-
-
Notifications
You must be signed in to change notification settings - Fork 315
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[LiveComponent] AsLiveComponent attribute inheritance #2236
Comments
parent::__construct($name, $template, null, true, 'attributes', false, 'ux_data_table', 'post', UrlGeneratorInterface::ABSOLUTE_PATH);
I assume this is just for illustration purposes, as forcing On a more serious note, this is something doable for Symfony >= 7.1 , so it might be easier to wait for the 3.x version of LiveComponent. What do you think? |
Let’s just say demonstrative purposes 😅. It’s beside the point but we’ve had multiple reports from different users of csrf throwing errors and causing 400s, so we decided to disable it on non-mutative components and accept the csrf risk rather than cause issues for real users. This feature would allow us to re-enable it on a later date for everyone without having to update every dependant.
Our bundle is more of a platform than just a bundle, we provide security.yaml from our own flex repo, we provide a custom kernel, our own routing,...
What would be the timeline for this? And without this feature in Symfony, is it something bundles could replicate (maybe even in 6.4)? |
I'm hoping early 2025.. On my side, I have a lot of features i'd like to work on, and many "bug" reports to deal with...
Nope, there is no point to replicate something already available in Symfony 7.1 I guess one possibility would be to allow it... for users using Symfony 7.1 (but we won't document it then, as we don't handle multiple versions at a time for now). So let's say there is not technical issue here. The next steps would be:
There is an ongoing work to extract metadata from these attributes, so the next step will probably be to split AsTwigComponent and AsLiveComponent... and then we could do it i suppose. Or ... we need to work on a method to register components without the AsLiveComponent attribute on the class... but that raises a lot of other questions. 🤷♂️ |
It would be great if
AsLiveComponent
could be extended to pre-fill certain values when working on Symfony bundles built on the shoulders of symfony/ux.Real world use-case:
I currently provide a DataTable driven by LiveComponent in one of my bundles. The bundle, and users of the bundle are currently required to use the
AsLiveComponent
attribute, like so:This request would be so that "MyBundle" could provide an attribute,
#[AsTable()]
, which would both fill params, and enforce certain values that are expected to be set that way by default. This would enable us to change the underlying default template location, routes, attributes,... without causing a backwards compatibility break for users of the bundle.For example:
Work required:
Currently
AsLiveComponent
is marked final, so that would have to go.Other than that, I have no clue what the implications could be for subscribers, dependency injection,... I assume these aren't built to deal with attribute class inheritance?
The text was updated successfully, but these errors were encountered: