[LiveComponent] Add the live.component service tag

[jakubtobiasz]

Q	A
Bug fix?	no
New feature?	yes
Issues	n/a
License	MIT

Currently we've been forced to use twig.component tag to configure live components manually. It required a lot of boilerplate code and sometimes could cause some issues when a new attribute has appeared (we faced with it once or twice in Sylius). So, the idea is to add a live.component service tag, which will be translated into twig.component tag 🕺🏻.

Time spent on this feature has been sponsored by Commerce Weavers ♥️.

[smnandre]

Hey! I think this will require a bit of time to study, cause it raises some questions we already had hard times on regarding what we allow to be configured / overwritten by bundles or not, and the order of registration :)

But i like the idea :)

[smnandre]

Could you create a separate PR for this change ?

[jakubtobiasz]

Sure thing, the question is whether we want (or must) do it this way. It's a little hack, but on the other hand, the question is whether we need this information in the CI.

[smnandre]

Is this absolutely necessary ?

[jakubtobiasz]

Of course it isn't. But I decided to add it as:

1. it makes testing compiler passes, extension and other things way easier
2. we're using it in Sylius, and it's a trustworthy dependency

If you want, I can remove it and test the compiler pass other way, but if we plan to create more tests covering extensions/compiler passes, it might be cool to leave it.

[kbond]

I really like this package - as config/compiler passes get more complex it's super useful - let's keep it!

[kbond]

@jakubtobiasz, for probably v2.18 or v2.19, we're going to really nail down the best practice for providing twig/live components in bundles. Do you have any suggestions on this (aside from this PR)?

• The twig template is straight forward as we can use the standard bundle overrides.
• We're not sure about component class overrides. One idea I floated was if you have a twig component that extends a 3rd party one, we merge the config (with the user defined config taking presidence).

[jakubtobiasz]

@kbond what config do you mean 🤔?

I didn't take a look at extendibility (yet), but I bet (as usually) decorating/extending the class + optionally override the template. In Sylius we have to care only about the class, because it's our "source of data". In terms of templates, we're using our hooks system, so we don't need to worry about templates 😅.

[kbond]

what config do you mean 🤔?

The tag/attribute config:

// in bundle
#[AsLiveComponent(...)]
BaseButtonComponent {}

// in app
#[AsLiveComponent(...)]
ButtonComponent extends BaseButtonComponent {}

We'd merge the ButtonComponent's tag attributes with BaseButtonComponent.

[jakubtobiasz]

@kbond keep in mind that the official recommendation is to not using attributes/annotations inside the bundles.

So, the configuration on the bundle-level should be done with using .xml file and the live.component attribute. If someone wants to change anything, they should override the service with using the .yaml (or any other format) file. Alternatively, they can extend the original service and create a new one basing on it. Also the component can be decorated.

[smnandre]

But props or methods do need Attributes right ?

[kbond]

keep in mind that the official recommendation is to not using attributes/annotations inside the bundles.

Yeah, I have been thinking to make an exception for twig/live components just because I think the tag config is a lot (but maybe that's just me).

[jakubtobiasz]

But props or methods do need Attributes right ?
Yup, but it's a class-level metadata, not related to the DI, which is the main reason why attributes are not recommended for bundles.

If you extend a class, and you want to change anything in existing attributes, you have to declare the attribute on your own.

Yeah, I have been thinking to make an exception for twig/live components just because I think the tag config is a lot (but maybe that's just me).

We might think of moving some configuration from the tag level to a getter inside the component. So, you can define a template on a tag level or inside the getTemplate(): string method (similarly like extending forms is solved).

[jakubtobiasz]

@kbond @smnandre I've updated the PR :); I've implemented similar solution directly in Sylius, and it seems to work fine :).

[kbond]

We are having a lot of discussions on how bundles can register components.

There is nothing stopping this but I am a bit concerned about bundles auto-registering live components. This could lead to security issues: even if not using a bundle's live component in your app, it can still be accessed via the HTTP endpoint.

[smnandre]

We're almost there @jakubtobiasz ! Don't lose hope :))

[jakubtobiasz]

If you need anything from me, feel free to reach me out here or on the Slack :); I have more space now than in Jun/Jul.

[smnandre]

Do you have an idea to allow Bundles to expose live components but

• "force" some prefix per bundle (like what we are doing for Twig components)
• add one "manual" action from user (can be via flex) to explicitely import them (like what's done for routes often? any other idea?)

My point is exactly what @kbond said: a bundle should not expose "automatically" endpoints ( _live/AcmeFoo is a sort of endpoint)

(available on Slack if you want to discuss this more in details)

[jakubtobiasz]

"force" some prefix per bundle (like what we are doing for Twig components)

I have created something like that here. You can't fully force that, but the question is whether we should. Symfony allows to create most of the things without strictly checking the name convention (services, routes).

In terms of security – maybe we should not expose bundles' components under the same root. Rather we should encourage (force 😂) bundles developers to create their own and take care about securing them 🤔? If we think that currently bundle can provide any route exposing any data it seems similarly secure.

[smnandre]

Symfony allows to create most of the things without strictly checking the name convention (services, routes).

Not the templates :)

No bundle should ever have the priority on the user.. but for now it's first arrived / first served regarding component names (and Bundle do register first)

But, above all: a bundle component should have a predefined unique name (or at least should have one predefined name).. This is the only way to allow bundle components to be nested / call other ones inside the bundle.

--

After #2019 and before LiveComponent.... i think the next step would be to support class-based TwigComponent(s) exposition from bundle.

That way we can focus on naming issues, class-override possibilities (or not), attribute...

And then we only have to deal with security considerations for LiveComponent ... wdyt ?