AlpineJS specific attributes are not rendered (@click and x-on:click)

[loevgaard]

I love the components, so thank you <3

I have a button component and I would like to be able to do:

<twig:Button value="Toggle" x-on:click="open = !open"/>

but the x-on:click attribute is not rendered with this Twig:

<button{{ attributes }}>{{ value }}</button>

instead it just strips the attribute and outputs:

<button>Toggle</button>

If I try to use the @click syntax, Twig throws an exception.

[norkunas]

I think this collides with newly implemented nested attributes.
In your case it would be accessible with attributes.nested('x-on') which in your case is unexpected :)

[kbond]

Ah yes, I think @norkunas is correct. Anyone have any thoughts on how to solve?

If I try to use the @click syntax, Twig throws an exception.

I think this could be a html-twig component parsing issue.

[smnandre]

What does the expection say ? In the end i'm not surprised as it's not valid HTML syntax. But if we can improve this let's do it :)

[loevgaard]

I think this collides with newly implemented nested attributes.
In your case it would be accessible with attributes.nested('x-on') which in your case is unexpected :)

Now that you pointed me in the right direction, it's totally fine for me :)

I will let you guys close the issue if you believe this is not something you want to 'fix'. For me, when I know what I know now, it's perfect :)

Once again, thanks for a great component!

[WebMamba]

I think this is legit issue we should keep it open. I don't really know how to solve it... Should we detect alpine attribute? Or should we add a prefix so that the attributes are ignore by the nested? Should we add a prefix for every nested attribute like <twig:Form twig:row:label='password' />?

[loevgaard]

I don't know if it's possible, but there's also the option to use another separator for nested attributes, e.g. dot:

<twig:Button value="Toggle" nested.attribute="Value"/>

But then again, that might conflict with something else...

[WebMamba]

But then again, that might conflict with something else...

Yes this is my worries!

[kbond]

Yeah, no matter what syntax we use, the possibility for conflicts exists. Some quick ideas:

1. Make the nested separator configurable
2. Add a prefix exclude-list
3. Some kind of escape syntax (ie !x-on:click)

1 & 2 above don't address the issue of using components from 3rd party bundles that would use the default syntax (and be unaware of your configuration). 3 feels like the best but introducing a new syntax isn't ideal.

Now that you pointed me in the right direction, it's totally fine for me :)

I'm glad there's a workaround but still, it's a bit of a bummer. I agree, let's keep this open.

[loevgaard]

The practical approach would be to do the research of the top 10-20 JS libraries that use this kind of syntax and see how they do it and make an informed decision based on that. Then at least it would hurt the least amount of people. Just thinking out loud :)

[WebMamba]

This can be a good solution, but some librairies can have conflic, and all of this convention could lead to limitation to the user. So I am not sure about this solution as well

[smnandre]

Do we accept "dashes" in the component names ? Maybe we could say if "x-...:" it is not a nested param ?

[loevgaard]

With the knowledge of nested attributes I just tried this:

<twig:Button x-on:click="hidden = false" value="Test"/>

and this

<button{{ attributes.nested('x-on') }}>{{ value }}</button>

and it renders as

<button click="hidden = false">Test</button>

which made me read the docs, and of course it makes sense, but now the user experience of adding these AlpineJS directives just got a bit worse in my opinion. Now I have to prepend x-on: to every value in the attributes.nested('x-on') collection.

Here's my code to do that:

{% set xOnAttributes = attributes.nested('x-on') %}
{% set xOn = '' %}
{% for attr, value in xOnAttributes %}
    {% set xOn = ' x-on:' ~ attr ~ '="' ~ xOnAttributes.render(attr) ~ '"' ~ xOn %}
{% endfor %}

This is pretty ugly :D

Ended up making a twig filter like this:

<?php

declare(strict_types=1);

namespace App\Twig\Extension;

use Symfony\UX\TwigComponent\ComponentAttributes;
use Twig\Extension\AbstractExtension;
use Twig\TwigFilter;

final class Extension extends AbstractExtension
{
    /**
     * @return list<TwigFilter>
     */
    public function getFilters(): array
    {
        return [
            new TwigFilter('nested_attributes', $this->nestedAttributes(...), ['is_safe' => ['html']]),
        ];
    }

    public function nestedAttributes(ComponentAttributes $attributes, string $namespace): string
    {
        $attributes = $attributes->nested($namespace);

        $output = '';

        foreach ($attributes as $attr => $_) {
            $output .= sprintf(' %s:%s="%s"', $namespace, $attr, $attributes->render($attr));
        }

        return $output;
    }
}

then I can output the x-on nested attributes like this:

<button{{ attributes|nested_attributes('x-on') }}>{{ value }}</button>

To make attributes.nested('x-on') the way I first wanted it to, we could change the signature of the method like this:

public function nested(string $namespace, bool $includeNamespace = false): self

if $includeNamespace is true we will preprend the namespace when creating the new list of attributes.

[smnandre]

I don't think we will change the nested contract.

But, i checked, you cannot create a blog foo-bar, so i really think we could change the nested regex to consider x-on as an attribute and not a nested prop 🤷

[smnandre]

@kbond would that be ok for you ?

[kbond]

Totally agree that - should be included in the regex!

As a solution to this issue, another idea: :: to escape? x-on::click renders as x-on:click?

[kbond]

I believe #1959 & #1960 together would resolve this issue.

[loevgaard]

You're the best, @kbond. Thank you 🎉

[kbond]

@loevgaard are you ok with the escape solution for :?

[loevgaard]

First off I thought it was great, but now I just gave it some thought, and it might be weird for people (not knowing about this PR and issue) that there are two :: when the syntax is one.

However, I think when #1960 is done, that solution is what most (if not all) will resort to. I think I used x-on: because @ didn't work. You can read about the x-on here: https://alpinejs.dev/directives/on. Maybe the 'correct' solution would be to make @ and tell AlpineJS users that they have to use @?

[kbond]

First off I thought it was great, but now I just gave it some thought, and it might be weird for people (not knowing about this PR and issue) that there are two :: when the syntax is one.

I added a note to the doc but this is a fair critique. The addition of "more hardcoded syntax" isn't ideal to begin with...

Maybe the 'correct' solution would be to make @ and tell AlpineJS users that they have to use @?

Hmm, are there advanced use cases where the @ cannot be used?

[loevgaard]

Hmm, are there advanced use cases where the @ cannot be used?

Not that I know of, but I am not an expert. I reached out to @jasonlbeggs. If he has time, he might give us some input.

[jasonlbeggs]

In my experience, x-on and @ are pretty much always interchangeable. When using Alpine with Laravel Blade, there are occasionally conflicts using the @ syntax since Blade uses @ for it's directives.

Long story short, I can't think of any downsides to supporting @ prefixes on attributes and using that syntax for Twig components.

[kbond]

Thanks @jasonlbeggs!

So perhaps let's roll with just #1960 to consider this issue fixed?

[loevgaard]

So perhaps let's roll with just #1960 to consider this issue fixed?

Yes, I do think so, Kevin. Thank you!

[kbond]

Big thanks to @smnandre for fixing the @ issue in #1966! As discussed, we'll forgo escaping : for now.

[ottaviano]

hey guys, what do you think about this ?

<twig:Button x-bind:class!="hey">My button</twig:Button>

#2325