-
-
Notifications
You must be signed in to change notification settings - Fork 308
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
Twig/LiveComponent Attributes #106
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this approach!
I quickly discussed this on Slack already, but I think we should use a DI tag + It does require some rewriting of the renderer though, as it currently uses the attribute at runtime. Is there anyone that can share their experiences with attributes on which approach is the best (based on performance or other thing that we didn't come up with)? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You were just a bit ahead of me.. I hadn't seen this PR and was working on an almost identical implementation ;) Looks good so far!
src/TwigComponent/src/DependencyInjection/Compiler/TwigComponentPass.php
Outdated
Show resolved
Hide resolved
src/TwigComponent/src/DependencyInjection/Compiler/TwigComponentPass.php
Outdated
Show resolved
Hide resolved
I now use The failing test is related to components with the same name. I no longer ensure they are unique. Right now, the last one registered wins. Thoughts? Should I add a compiler pass to ensure they are unique? (I believe a compiler pass is the only way) Also, I now require Symfony 5.3+ so I can use |
I vote for last one wins - like service id's
If it's just a matter of doing a |
Do we want the |
I went with this.
Manual tagging/4.4+ is now supported (I haven't updated the gh action to prove this). PHP8 and the |
Maybe? Right now we only have name and template options... but there is already the question of:
And, what if we have more options in the future? I can envision that, if we decide to put it all on the tag, then we would, in a compiler pass, push that tag data into some sort of "component metadata service" where we would probably have a method like So I think we should NOT do this. We should follow the API Platform model (or the Doctrine entity model) where the metadata is pulled lazily at runtime when needed. The only stuff in the tag is the stuff that is useful to know without needing to instantiate the objects (e.g. with commands, it's nice to know the name of each command without instantiating it, and the same with Twig components). If we were to make the PHP8 attribute optional, I think it makes sense to do so with an alternate configuration format - e.g. a PHP config format (like routing config or validation config). |
What happens if it doesn't? It seems like an odd situation, but I would imagine that the tag |
I agree.
For twig components, I don't believe it will be a problem as we never, at runtime, get the component name from the class. For live components, as of right now, the url is generated with the name the component class gives. The subscriber would look for the component based on the DI tag so there could be a mismatch. I could enforce this in the compiler pass. |
Fair points @weaverryan, I agree. |
Alternatively, and I think I prefer this, I can remove the requirement to set a tag |
I think the TwigComponent refactor is complete and ready for review. I added a GH action job to run on php8 with low deps to prove it's compatible with 4.4.
I went with this. No possibility for a mismatch. The "name" is now only pulled from the attribute. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comments - but this looks really solid! Let's roll this into LiveComponents 👍
src/TwigComponent/src/DependencyInjection/Compiler/TwigComponentPass.php
Outdated
Show resolved
Hide resolved
src/TwigComponent/src/DependencyInjection/TwigComponentExtension.php
Outdated
Show resolved
Hide resolved
48f8f5e
to
1eee8ae
Compare
I have switched LiveComponents to PHP8 attributes (only) so this is ready for another round of reviews (ping @dbrekelmans, @weaverryan).
|
private LiveProp $liveProp; | ||
private \ReflectionProperty $reflectionProperty; | ||
|
||
public function __construct(LiveProp $liveProp, \ReflectionProperty $reflectionProperty) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As the package now requires PHP 8, wouldn't it be interesting to use constructor property promotion here and in other classes where it can be implemented?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Absolutely, I didn't use these PHP 8 features as it breaks the php-cs-fixer job for the mono repo. I'm not sure how we want to handle this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor notes - this is looking great!!!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work @kbond!
d177254
to
4d3c8e8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Thank you Kevin for this huge work!! |
This PR was squashed before being merged into the main branch. Discussion ---------- Twig/LiveComponent Attributes | Q | A | ------------- | --- | Bug fix? | no | New feature? | no | Tickets | - | License | MIT Based on discussions with `@weaverryan`, the consensus from the core team seems to be to require PHP8+ and use attributes for defining components instead of the interface. The updated [readme](https://github.com/symfony/ux/blob/a80d8df64a41860d2fec407dfecac36ce34809a1/src/TwigComponent/README.md) shows how this would now work. Assuming this is the direction we want to go, I will update the `LiveComponent` package. Todo: - [x] Update `LiveComponent` - [x] Fix duplicated `LiveProp` [issue](symfony/ux#106 (comment)) on parent classes Commits ------- 46777c3 Twig/LiveComponent Attributes
This PR was squashed before being merged into the main branch. Discussion ---------- Twig/LiveComponent Attributes | Q | A | ------------- | --- | Bug fix? | no | New feature? | no | Tickets | - | License | MIT Based on discussions with `@weaverryan`, the consensus from the core team seems to be to require PHP8+ and use attributes for defining components instead of the interface. The updated [readme](https://github.com/symfony/ux/blob/a80d8df64a41860d2fec407dfecac36ce34809a1/src/TwigComponent/README.md) shows how this would now work. Assuming this is the direction we want to go, I will update the `LiveComponent` package. Todo: - [x] Update `LiveComponent` - [x] Fix duplicated `LiveProp` [issue](symfony/ux#106 (comment)) on parent classes Commits ------- 46777c3 Twig/LiveComponent Attributes
This PR was squashed before being merged into the main branch. Discussion ---------- Update for twig/live component attribute refactor This is a companion PR for symfony/ux#106. Commits ------- beb13ee Update for twig/live component attribute refactor
This PR was merged into the main branch. Discussion ---------- Adding CHANGELOG for twig/live component | Q | A | ------------- | --- | Bug fix? | no | New feature? | no | Tickets | none | License | MIT Follow up of #106 to help people track what's changing. Commits ------- ddac904 Adding CHANGELOG for twig/live component
This PR was merged into the main branch. Discussion ---------- [bug] remove duplicated doctrine/annotations entry | Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | Tickets | n/a | License | MIT Looks like 2 different PR's added this. (#111 and #106) Commits ------- 5b9ea2d [bug] remove duplicated doctrine/annotations entry
This PR was squashed before being merged into the main branch. Discussion ---------- Twig/LiveComponent Attributes | Q | A | ------------- | --- | Bug fix? | no | New feature? | no | Tickets | - | License | MIT Based on discussions with `@weaverryan`, the consensus from the core team seems to be to require PHP8+ and use attributes for defining components instead of the interface. The updated [readme](https://github.com/symfony/ux/blob/a80d8df64a41860d2fec407dfecac36ce34809a1/src/TwigComponent/README.md) shows how this would now work. Assuming this is the direction we want to go, I will update the `LiveComponent` package. Todo: - [x] Update `LiveComponent` - [x] Fix duplicated `LiveProp` [issue](symfony/ux#106 (comment)) on parent classes Commits ------- 46777c3 Twig/LiveComponent Attributes
This PR was squashed before being merged into the main branch. Discussion ---------- Twig/LiveComponent Attributes | Q | A | ------------- | --- | Bug fix? | no | New feature? | no | Tickets | - | License | MIT Based on discussions with `@weaverryan`, the consensus from the core team seems to be to require PHP8+ and use attributes for defining components instead of the interface. The updated [readme](https://github.com/symfony/ux/blob/a80d8df64a41860d2fec407dfecac36ce34809a1/src/TwigComponent/README.md) shows how this would now work. Assuming this is the direction we want to go, I will update the `LiveComponent` package. Todo: - [x] Update `LiveComponent` - [x] Fix duplicated `LiveProp` [issue](symfony/ux#106 (comment)) on parent classes Commits ------- 46777c3 Twig/LiveComponent Attributes
This PR was squashed before being merged into the main branch. Discussion ---------- Twig/LiveComponent Attributes | Q | A | ------------- | --- | Bug fix? | no | New feature? | no | Tickets | - | License | MIT Based on discussions with `@weaverryan`, the consensus from the core team seems to be to require PHP8+ and use attributes for defining components instead of the interface. The updated [readme](https://github.com/symfony/ux/blob/a80d8df64a41860d2fec407dfecac36ce34809a1/src/TwigComponent/README.md) shows how this would now work. Assuming this is the direction we want to go, I will update the `LiveComponent` package. Todo: - [x] Update `LiveComponent` - [x] Fix duplicated `LiveProp` [issue](symfony/ux#106 (comment)) on parent classes Commits ------- 46777c3 Twig/LiveComponent Attributes
This PR was merged into the main branch. Discussion ---------- [bug] remove duplicated doctrine/annotations entry | Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | Tickets | n/a | License | MIT Looks like 2 different PR's added this. (symfony/ux#111 and symfony/ux#106) Commits ------- 5b9ea2d [bug] remove duplicated doctrine/annotations entry
Based on discussions with @weaverryan, the consensus from the core team seems to be to require PHP8+ and use attributes for defining components instead of the interface. The updated readme shows how this would now work.
Assuming this is the direction we want to go, I will update the
LiveComponent
package.Todo:
LiveComponent
LiveProp
issue on parent classes