lint:twig error, possibly with twig component

[tacman]

I've opened an issue at symfony/symfony#52778, but posting here because I think it may have to do with symfony/ux-twig-component.

I wonder if I should actually post this to twigphp/twig?

I'm pretty sure it's a bug that was recently introduced, as I think the template referenced used to work. @kbond , can you take a quick peek and at least tell me where to post this issue?

[smnandre]

I'm not sure, but are you using <twig:block in a non-embeded context ?

<twig:block is not equivalent to the {% block %} tag, it's only usable inside a embeddable Twig Component.

The block tag may be used in include / extends context for example, <twig:block cannot

If i missunderstood your usage please tell me :)

[tacman]

Hmm, I've been using it as a replacement for {% block %}, but perhaps it was coincidental that it used to work.

I suspect that if I cleaned up the mess of blocks (obviously, I was in the middle of migrating to the new style), I could get it to work. But certainly the lint:twig command should point me to a hint as to where the problem is.

[smnandre]

That is not related to the lint:twig command but to our implementation of the TwigComponent custom PreLexer.

I must admit that, personnaly, have a lot to do before i spend time on improving this particular case, but let's see next weeks/months if this becomes a common problem

Thank you for finding / submitting all those issues: it really helps improving the UX components !

[tacman]

I fixed it with

        if (strlen($this->input) >= $this->position) {
            return false;
        }

And got the error message I was expecting. Okay to submit a PR?

[smnandre]

PR are always welcomed :)

[smnandre]

But i need to insist, for you to not be surprised if (when?) that happens...

The <twig:block > syntax is currently uniquely supported inside embedded components.

It "works" by chance for you there, but this is not something intented and could stop to work at any time

[smnandre]

In fact, if you replace your <twig:block name="gridTable"> and replace it by {% block gridTable %} ... no more errors :)

And i think I understand why and ... what need to be fixed because it could have other consequences

So i'm really sorry but you found a bug that... when corrected, may also stop accepting this outside-component behaviour :/

[tacman]

@smnandre

In my templates that extend base.html.twig, I'm able to use either of these (but not both at the same time!) to define the title block.

{% block title %}Officials{% endblock %}
<twig:block name="title">Officials</twig:block>

I just like the syntax better, I think it looks cleaner. But thanks for the heads-up that it might not work. I have a bundle that totally depends on these twig blocks that appears to have broken in the latest dev version, based on this off-book behavior. Uh oh!

[tacman]

Argh. Here's the use case that is now failing with the dev branch of ux. I have a component that renders a table. Each table column can be rendered within its own block, matching the name of the variable.

    {% component grid with {
        data: data,
        columns: [
        'id',
        {name: 'birthday', sortable: true},
    } %}

        <twig:block name="birthday">
            {{ row.birthday|date('Y-m-d') }}
        </twig:block>
    {% endcomponent %}

Within the component, it renders the value by default, but if a block (within the component) exists, it uses that block to render the value. It works great.

There are other issues, but this seems like it should work, since it's a twig:block within a component.

I

[tacman]

There's some change in the dev branch that handles parsing blocks differently.

Here's another example.

<twig:grid :data="data" tableId="example" :columns="columns" useDatatables="false">        
    <twig:block name="id">            {{ row.id }}        </twig:block>    
</twig:grid>

My component passes "row" to the block to be rendered.

https://github.com/survos/SurvosApiGridBundle/blob/main/templates/components/grid.html.twig#L41-L56

 {% set blockParams = {field_name: c.name, row: row, column: c, c:c } %}
                     
                            {% with blockParams %}
                                {{ block(templateName) }}
                            {% endwith %}

I realize that this is an edge case, defining blocks that are effectively templates, but it's worked great! In fact, these same templates can be compiled to javascript (via twigjs) and used in dynamic datatables. It's actually really cool, to define dynamic rendering for datatables in twig.

I love this ability. Please consider allowing it. Thanks.

[tacman]

Sorry if this is redundant, but I'm starting to panic. The following works with the current release of ux-twig-component, but the twig:grid fails with the dev branch:

    <h3>using component</h3>
    {% component 'grid' with {
        data: data,
        columns: columns
    } %}
        {% block title %}
            <i>{{ row.title }}</i>
        {% endblock %}
    {% endcomponent %}

    <h3>using twig:grid</h3>
    <twig:grid :data="data" tableId="example" :columns="columns">
        <twig:block name="title">
            <i>{{ row.title|default('throws a compile error without default') }}</i>
        </twig:block>
    </twig:grid>

[smnandre]

I'm gonna fix the block bug to start, and we'll see where it goens from here.

There is something wrong with the Lexer

<twig:block name="foo">
    {#  {% block a %} #}
</twig:block>

This should throw an exception, not a strlen error.

[tacman]

[removed, irrelevant]