Not planned
Description
These may be two very different reports with different opinions for each, so please let me know if you'd like me to separate them.
Example 01: Passing attributes as-is
<twig:Comp {{ attributes }} /> {# ❌ original question/report #}
<twig:Comp {{ ...attributes }} /> {# ✅ the correct way #}
A realistic usecase for this is creating higher-order (wrapper) components.
Example 02
<twig:Comp
{% if condition %}
disabled
{% endif %}
/>
Most notably, without these conditions, boolean attributes seem impossible (?), but would also just make the syntax more consistent with the way Twig is normally written.
Both result in:
Expected attribute name when parsing the "<twig:Comp" syntax.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
Kocal commentedon Dec 19, 2024
What about
<twig:Comp {{ ...attributes }} />
?eokic commentedon Dec 19, 2024
Ah dangit, somehow that documentation bit kept eluding me 🤦🏻. Maybe to mention it again briefly under
#component-attributes
? That's definitely where I've spent most of my time looking for it. Spread seems to work as expected so I'll give it a go, thank you!Kocal commentedon Dec 19, 2024
Mmmh, I don't know, because it is related to the HTML syntax 🤔
But maybe it can be interesting to also have it in this section, do you feel opening a PR? 🙏🏻
eokic commentedon Dec 20, 2024
Completely understandable; I can only speak from my own experience as someone who's been periodically consuming that documentation over the course of a few months and yet still managed to not stumble upon the info in question 😅
Sure thing, opened as #2457
smnandre commentedon Dec 20, 2024
You cannot do this to pass parameters to an include or embed block in Twig. So this is all but a bug :)
I’m closing here as thanks to you the first item will be better documented.
eokic commentedon Dec 21, 2024
Disagree. I am not comparing it with
include
orembed
as that's a different syntax; closer to{{ component('Alert', ... }}
.This is comparable to (and to a large degree emulates) regular HTML like:
smnandre commentedon Dec 21, 2024
This is not comparable, in fact.
Using
<twig:Comp ...>
is exactly like typing {{ component('Comp') }} in fact.And you cannot type
{{ component('Comp', {% if condition %}... ) }}
because you cannot use tags inside an expression, a function, a filter, ...eokic commentedon Dec 27, 2024
Just to clarify and confirm if we're on the same page; the TwigComponent HTML syntax is syntactic sugar and therefore implementing tags like
{% if %}
brings along certain technical challenges when you try to map it to the{{ component() }}
syntax? Especially if we want to map this exactly (1:1) from one syntax to the other.smnandre commentedon Dec 27, 2024
Absolutely. You could also see it as an "extension" of the Twig language.
This is not really a something related to the HTML syntax but to Twig. And languages in general. Tags cannot be opened in other tags or in expressions. In the same way you cannot in php use a structure in a method call.
Well, as i see it, this works in the opposite direction.
Twig Component features are developed in (Twig and PHP) then supported in the HTML syntax.
The choice of implementing it using the
component()
function it is only a choice of simplicity. We could totally use a different function or tag if it offered advantages.