Add <twig:Turbo:Stream:*> components

[nicolas-grekas]

Q	A
Bug fix?	no
New feature?	yes
Issues	-
License	MIT

This PR provides Twig components for turbo-streams:

<twig:Turbo:Stream:Append target="#some-id">
    <div>Append this</div>
</twig:Turbo:Stream:Append>

Sibling PR to #2196
See #2196 (comment) for some background.

[Kocal]

LGTM, can you add some tests to check that components nicely render please?
Thanks :)

[neluba]

I don't know if the symfony phpstorm plugin works with third party components, but it might incorrectly offer autocompletions for all properties on all components, because they're inherited from TurboStreamComponent.

[nicolas-grekas]

I figured out I could use anonymous twig components, so here we are. Tags are now like:

<twig:Turbo:Stream:Append target="#some-id">
    <div>Append this</div>
</twig:Turbo:Stream:Append>

[rvmourik]

I figured out I could use anonymous twig components, so here we are. Tags are now like:

<twig:Turbo:Stream:Append target="#some-id">
    <div>Append this</div>
</twig:Turbo:Stream:Append>

Is there a specific reason why the attribute is called target and in the HTML using targets?

[nicolas-grekas]

Is there a specific reason why the attribute is called target and in the HTML using targets?

Good question. Turbo accepts both target and targets. The former accepts an HTML id, the latter a CSS selector.
IMHO this is provides bad DX. Using a CSS selector should be the only way: when reading #id, it's way clearer that we target an id, and also it's hinting that another CSS selector would work.

I'm for not supporting Turbo's target attribute.
Then, which name should we give to the CSS-selector attribute on our side? target looks the most sensible to me.
We could name it targets, but the "s" feels unnecessary.

[rvmourik]

Is there a specific reason why the attribute is called target and in the HTML using targets?

Good question. Turbo accepts both target and targets. The former accepts an HTML id, the latter a CSS selector. IMHO this is provides bad DX. Using a CSS selector should be the only way: when reading #id, it's way clearer that we target an id, and also it's hinting that another CSS selector would work.

I'm for not supporting Turbo's target attribute. Then, which name should we give to the CSS-selector attribute on our side? target looks the most sensible to me. We could name it targets, but the "s" feels unnecessary.

I think target is the way to go, but maybe elaborate on the target/targets difference in the docs so people don't mistake the target attribute of the component with the HTML target attribute.

Nevertheless, great DX improvements with the two PR's 👍

[kbond]

❤️

[nicolas-grekas]

#2230 should be fixed for tests to be green.

[nicolas-grekas]

All green :)

[Kocal]

PR rebased and conflicts fixed, I merge when the CI is green.

[Kocal]

Thank you Nicolas! :)

[onEXHovia]

Is there any benefit from these components in a real application? This package can also be used without TwigComponent. Maybe we should be closer to the package https://github.com/hotwired/turbo-rails?

[nicolas-grekas]

The benefit is structured declaration: you cannot make a typo, the IDE can help you, etc.

[nicolas-grekas]

I don't about the turbo-rails package, so feel free to open issues/PRs with the specific things you think would be useful for Symfony apps. I'd be happy to review them.

[onEXHovia]

The benefit is structured declaration: you cannot make a typo, the IDE can help you, etc.

You right, but twig component not part of twig(I hope this will change) how blade+components in laravel. In projects where not used twig components will have to install +1 package, this could be a problem. Instead, we can use only twig functions:

{% turbo_stream 'apend', dom_id(todo) %}
{% turbo_frame_tag 'target' %}

I don't mind twig components with html syntax, but look at PR twigphp/Twig#3867 (comment) there are some problems with this. My idea is to use standard features twig to cover as many projects as possible.

[smnandre]

I love this PR, and this is such a good example of anonymous components exposed by bundles ! (thanks @yceruto again)

(note to myself: I'm thinking we should use this in the documentation to illustrate!)

Thank you @nicolas-grekas ❤️

[smnandre]

Also, in my mind there is no "feature" here that would need to be delivered without TwigComponent. Anyone can do something similar with pure Twig if they want (via embeds or macros).. but for those who have the TwigComponent installed, it's a great sugar syntax / DX improvement.

I don't mind twig components with html syntax, but look at PR twigphp/Twig#3867 (comment) there are some problems with this. My idea is to use standard features twig to cover as many projects as possible.

You then can use {{ component('Turbo:Stream', ... ) }} syntax.

It is 100.00% compatible with Twig standard features and will stay this way.