Skip to content
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

Merged
merged 1 commit into from
Jul 1, 2021
Merged

Twig/LiveComponent Attributes #106

merged 1 commit into from
Jul 1, 2021

Conversation

kbond
Copy link
Member

@kbond kbond commented Jun 21, 2021

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 shows how this would now work.

Assuming this is the direction we want to go, I will update the LiveComponent package.

Todo:

  • Update LiveComponent
  • Fix duplicated LiveProp issue on parent classes

Copy link
Member

@weaverryan weaverryan left a 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!

src/TwigComponent/src/Attribute/TwigComponent.php Outdated Show resolved Hide resolved
src/TwigComponent/src/Attribute/TwigComponent.php Outdated Show resolved Hide resolved
src/TwigComponent/src/Attribute/TwigComponent.php Outdated Show resolved Hide resolved
@wouterj
Copy link
Member

wouterj commented Jun 21, 2021

I quickly discussed this on Slack already, but I think we should use a DI tag + registerAttributeForAutoconfiguration() for configuring components (and name + template). That seems to be the standard for all other Symfony attributes and it adds a nice extra: It means we have support for PHP <8.0 and Symfony <5.3 if a user just adds the tag to the component services.

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)?

Copy link

@dbrekelmans dbrekelmans left a 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!

@kbond
Copy link
Member Author

kbond commented Jun 21, 2021

I now use registerAttributeForAutoconfiguration in lieu of the compiler pass. Twig components can also be manually configured by adding a twig.component tag with a key parameter for the name.

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 registerAttributeForAutoconfiguration but could allow older version if desired. On older versions, components could only be registered manually.

@weaverryan
Copy link
Member

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)

I vote for last one wins - like service id's

Also, I now require Symfony 5.3+ so I can use registerAttributeForAutoconfiguration but could allow older version if desired. On older versions, components could only be registered manually.

If it's just a matter of doing a method_exists() before calling that method, then I'm +1 for doing that and at least allowing 5.2 and lower users to use this library with manual tagging.

@kbond
Copy link
Member Author

kbond commented Jun 22, 2021

Do we want the AsTwigComponent to be completely optional as @dbrekelmans suggests above? Allow both the component name and template to be set manually via the twig.component tag? How should I map the component to a template for the ComponentRenderer? Build a component class => template map?

@kbond
Copy link
Member Author

kbond commented Jun 22, 2021

I vote for last one wins - like service id's

I went with this.

If it's just a matter of doing a method_exists() before calling that method, then I'm +1 for doing that and at least allowing 5.2 and lower users to use this library with manual tagging.

Manual tagging/4.4+ is now supported (I haven't updated the gh action to prove this). PHP8 and the AsLiveComponent is still required. Manual tagging is a little annoying as your key tag attribute must match your AsLiveComponent name property.

@weaverryan
Copy link
Member

Do we want the AsTwigComponent to be completely optional as @dbrekelmans suggests above?

Maybe? Right now we only have name and template options... but there is already the question of:

How should I map the component to a template for the ComponentRenderer? Build a component class => template map?

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 getMetadata($class) that would return an object that's very similar to the AsLiveComponent. But it would be tricky to make this service lazy (we would probably inject ALL of the tag data from ALL of the components into its constructor, so instantiating it would put that all into memory).

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).

@weaverryan
Copy link
Member

Manual tagging is a little annoying as your key tag attribute must match your AsLiveComponent name property.

What happens if it doesn't? It seems like an odd situation, but I would imagine that the tag name would "win" over the one in the attribute.

@kbond
Copy link
Member Author

kbond commented Jun 23, 2021

So I think we should NOT do this

I agree.

What happens if it doesn't?

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.

@dbrekelmans
Copy link

Fair points @weaverryan, I agree.

@kbond
Copy link
Member Author

kbond commented Jun 23, 2021

I could enforce this in the compiler pass.

Alternatively, and I think I prefer this, I can remove the requirement to set a tag key and configure the service locator in the compiler pass. This would remove any possibility of a mismatch when manually tagging.

@kbond
Copy link
Member Author

kbond commented Jun 23, 2021

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.

Alternatively, and I think I prefer this, I can remove the requirement to set a tag key and configure the service locator in the compiler pass. This would remove any possibility of a mismatch when manually tagging.

I went with this. No possibility for a mismatch. The "name" is now only pulled from the attribute.

Copy link
Member

@weaverryan weaverryan left a 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/README.md Outdated Show resolved Hide resolved
src/TwigComponent/README.md Outdated Show resolved Hide resolved
src/TwigComponent/README.md Outdated Show resolved Hide resolved
src/TwigComponent/README.md Outdated Show resolved Hide resolved
src/TwigComponent/src/ComponentRenderer.php Outdated Show resolved Hide resolved
@kbond kbond force-pushed the attributes branch 3 times, most recently from 48f8f5e to 1eee8ae Compare June 25, 2021 23:37
@kbond kbond marked this pull request as ready for review June 27, 2021 13:58
@kbond kbond requested a review from weaverryan June 27, 2021 13:58
@kbond
Copy link
Member Author

kbond commented Jun 27, 2021

I have switched LiveComponents to PHP8 attributes (only) so this is ready for another round of reviews (ping @dbrekelmans, @weaverryan).

Not sure why the coding-style-js job is failing.. Looks to be caused by the live component readme. fixed

private LiveProp $liveProp;
private \ReflectionProperty $reflectionProperty;

public function __construct(LiveProp $liveProp, \ReflectionProperty $reflectionProperty)
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Member

@weaverryan weaverryan left a 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!!!

Copy link

@dbrekelmans dbrekelmans left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work @kbond!

src/LiveComponent/README.md Outdated Show resolved Hide resolved
src/LiveComponent/README.md Show resolved Hide resolved
src/LiveComponent/README.md Outdated Show resolved Hide resolved
src/LiveComponent/README.md Outdated Show resolved Hide resolved
src/LiveComponent/src/Attribute/AsLiveComponent.php Outdated Show resolved Hide resolved
src/LiveComponent/tests/Fixture/Kernel.php Show resolved Hide resolved
src/TwigComponent/tests/Fixture/Kernel.php Show resolved Hide resolved
@kbond kbond force-pushed the attributes branch 2 times, most recently from d177254 to 4d3c8e8 Compare June 29, 2021 19:44
@kbond kbond requested a review from weaverryan June 29, 2021 19:57
Copy link
Member

@weaverryan weaverryan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@kbond kbond changed the title [WIP] Twig/LiveComponent Attributes Twig/LiveComponent Attributes Jun 30, 2021
@weaverryan
Copy link
Member

Thank you Kevin for this huge work!!

@weaverryan weaverryan merged commit 4e7cd8c into symfony:main Jul 1, 2021
symfony-splitter pushed a commit to symfony/ux-live-component that referenced this pull request Jul 1, 2021
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
symfony-splitter pushed a commit to symfony/ux-twig-component that referenced this pull request Jul 1, 2021
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
@kbond kbond deleted the attributes branch July 1, 2021 13:05
weaverryan added a commit to weaverryan/live-demo that referenced this pull request Jul 1, 2021
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
weaverryan added a commit that referenced this pull request Jul 1, 2021
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
weaverryan added a commit that referenced this pull request Jul 1, 2021
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
sadafrangian3 pushed a commit to sadafrangian3/twig-component-php that referenced this pull request Nov 2, 2022
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
gregoryross1211 added a commit to gregoryross1211/PHP-deve-twig-component that referenced this pull request Nov 11, 2022
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
jameswebapp added a commit to jameswebapp/ux that referenced this pull request Aug 1, 2023
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
jameswebapp added a commit to jameswebapp/ux that referenced this pull request Aug 1, 2023
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants