[TwigComponent] Unexpected attribute parsing behavior

[eokic]

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.

[Kocal]

What about <twig:Comp {{ ...attributes }} />?

[eokic]

What about <twig:Comp {{ ...attributes }} />?

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]

Maybe to mention it again briefly under #component-attributes? That's definitely where I've spent most of my time looking for it.

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]

Mmmh, I don't know, because it is related to the HTML syntax 🤔

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 😅

But maybe it can be interesting to also have it in this section, do you feel opening a PR? 🙏🏻

Sure thing, opened as #2457

[smnandre]

 <twig:Comp
  {% if condition %}
    disabled
  {% endif %}
/>

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]

You cannot do this to pass parameters to an include or embed block in Twig. So this is all but a bug :)

Disagree. I am not comparing it with include or embed as that's a different syntax; closer to {{ component('Alert', ... }}.

This is comparable to (and to a large degree emulates) regular HTML like:

<input
  {% if condition %}
    disabled
  {% endif %}
/>

[smnandre]

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]

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]

the TwigComponent HTML syntax is syntactic sugar

Absolutely. You could also see it as an "extension" of the Twig language.

therefore implementing tags like {% if %} brings along certain technical challenges when you try to map it to the {{ component() }} syntax

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.

// This is not possible (controle structure)
$obj->{if ($foo) { echo 'foo'; }}()

// This is possible (expression)
$obj->{$foo ? 'foo' : 'bar'}()

Especially if we want to map this exactly (1:1) from one syntax to the other.

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.