Outer Scope Blocks

[Phil23]

Hello folks,

We are currently evaluating using Twig UX components for the standard storefront of shopware. One important aspect for us is the extendability of shopware for our ecosystem.

One issue that we encountered so far is the mix of block scopes that is introduced when using components. We understand that using the block syntax for overriding default content within a component seems logical, but when using these components in a template that should also still be extendable, it limits the way you can access the actual content of the template. Especially when you make use of several nested components.

Example:
You have a template, let's call it page/example.html.twig, which can be extended and has some blocks with content in it. Within those blocks you use a bunch of Twig components.

{# page/example.html.twig #}

{% block main_navigation %}
    <twig:nav>
        <twig:nav:item>
            <twig:nav:link>Home</twig:nav:link>
        </twig:nav:item>
    </twig:nav>
{% endblock %}

If we want to make the navigation extendable, so that, for example, new items could be added, it is not possible to define blocks in the scope of page/example.html.twig because starting with <twig:nav> the scope changes to the inner of the nav component.

The only workaround we found so far is to define the inner content via a variable using set, but this makes the whole markup very messy, especially if you have several nesting levels.

{# page/example.html.twig #}

{% block main_navigation %}

    {% set navigationItems %}
        {% block main_navigation_items %}
            <twig:nav:item>
                <twig:nav:link>Home</twig:nav:link>
            </twig:nav:item>
        {% endblock %}
    {% endset %}

    <twig:nav>
        {{ navigationItems }}
    </twig:nav>
{% endblock %}

Maybe we are missing something here, so if you know of a better solution, we are more than happy to hear about it. We already worked through the documentation like Inheritance & Forwarding "Outer Blocks", but it seems there is no concept for defining outer scope blocks within component content.

Why not slots?
I know Twig already has the block system and using this syntax seems logical on first sight, but it is not quite the same as the concept of slots known from other famous component frameworks, or? Wouldn't it be better to have a separate syntax like {% slot %} to slot content into a component, so that the scopes aren't mixed up with outer page blocks?

[Kocal]

Hi!

First, thanks for considering us for Shopware :)

About your issue, I'm far from being a Twig and Twig components expert, but like you I find the current system a bit confusing, especially when coming from the Vue world when you can easily expose and use slots.

If I understand correctly, ideally you would write something like this? So the block main_navigation_items is easily overridable when extending page/example.html.twig file?

{# page/example.html.twig #}

{% block main_navigation %}
    <twig:nav>
        {% block main_navigation_items %}
            <twig:nav:item>
                <twig:nav:link>Home</twig:nav:link>
            </twig:nav:item>
        {% endblock %}
    </twig:nav>
{% endblock %}

I think this is not supported, I believe that when you are inside a Twig component context, you can't use Twig blocks like that.
On another note, mixing <twig> and {% block %} is not allowed, but that's not really the point here.
Replacing {% block main_navigation_items %} by <twig:block name="main_navigation_items"> is not related with what you expect.

Maybe do you @kbond and @smnandre have any hints? 🙏🏻

[Phil23]

Yes, that exactly describes the problem. It is currently the biggest argument against using Twig components because they remove the flexibility of creating page templates that can be extended properly.

[smnandre]

Hi @Phil23!

I think you're putting your finger on one of the main sources of confusion (or frustration) when it comes to TwigComponent.

Nothing revolutionary here, but as you know, 'slots' are widely used in frontend frameworks to expose areas meant to be filled in. However, as far as I know, there's no such thing as recursive or inherited slots that would allow overriding a very specific part of a component by extending the entire template (correct me if I'm wrong, of course!).

From what I understand, in the early days of Twig/LiveComponent, the goal was mainly to build isolated UI elements, leveraging PHP and Symfony for business logic, security, caching, etc., rather than to offer a full UI composition system.

At the time, they relied 100% on Twig, and most people used them through traditional Twig template architectures.

With the HTML syntax and anonymous templates, TwigComponent has attracted a broader audience, and that's a great thing. But the issue is… we never clearly separated the two concepts, because today they're still technically the same thing. (And in my personal opinion, they shouldn't be, at least not in terms of implementation.)

Long story short: trying to do prop or slot drilling and preserve Twig's powerful block inheritance system seems fundamentally incompatible, at least if we want to keep BC guarantees. And I fear it will just leave everyone confused.

That said, I do believe a slot system could work, but only under one condition: once you enter a component using slots, you switch to a 'slots-only' mode. Blocks no longer apply. And vice versa.

I'm just not sure yet how to introduce that idea in practice.

My personal take: if you ever need to make part of a component's HTML extendable from the outside (say, the right side of a footer, for instance), then maybe that footer is not really a component. And honestly, for that kind of layout work, nothing beats Twig's native block inheritance. It's more powerful than we often give it credit for.

That said, very happy to discuss this further – always open to new ideas, proposals, or fresh takes on the problem :)

[tobiasberge]

Hi @smnandre,

many thanks for your extensive answer. 😮

We have already suspected that this might be a bigger topic and nothing that can be adjusted easily because it would break current behaviour. 😅

I think it would be really cool when "slots" would "just" be placeholders (scoped to the component) to override content. Like e.g. in Vue.js. If I understand it correctly this is already kind of the case at the moment, but with the block syntax (Of course a bit oversimplified).

And on the other hand, the block system would remain as it is and allows extending "normal" Twig templates. Or in other words: Those are different mechanisms.

For example:

{# product-card.html.twig #}

{# This is a Twig component #}

<article class="product-card">

   {# This is a slot, scoped to this component #}
   {% slot image %}
       <div class="product-card-image">
   {% endslot %} 

   {% slot name %}
       <h2>{{ productName }}</h2>
   {% endslot %}

   {% slot price %} 
       <p>{{ productPrice }}</p>
   {% endslot %}
</article>

{# product-list.html.twig #}

{# This is the usage of the Twig component #}

<twig:product-card 
   productName="Example product" 
   price="$50,00"
>
    {# The slot "name" is used to override the HTML, like it would be right now with <twig:block name="name"> #}
    <twig:slot name="name">
        {# Now a block is declared within a slot of the component usage. #}
        {# However, the block has "nothing to do" per se with the component itself, it is in the scope of the template that uses the component. (product-list.html.twig) #}
        {% block product_name %} 
            I override the name slot with some special HTML
        {% endblock %}
    </twig:slot>
</twig:product-card>

{# product-list-extension.html.twig #}

{# Now somebody wants to extend the template, that is using the Twig component #}

{% extends '@Storefront/some/path/product-list.html.twig' %}

{# The product_name is overwritten on the scope of product-list.html.twig #}
{# The rendered content is inside the product card. #}
{% block product_name %} 
    I would like to extend the product-list template
{% endblock %}

The reason that something like this would be so helpful for us is, that we already use the block/extends system quite extensively to allow customising the Storefront HTML.

However we are currently lacking a proper UI component system and we are somewhat "mimicking" components with include templates. {% include '@Storefront/component/product-card.html.twig' with { someVar: 'wusel' } %}. And having actual nice components like with UX components would be much cleaner and offer a better dev-experience.

For us it would be cool to introduce UX components and use them in our templates, but still allow extending the templates where the components are used.

Of course the example above was a bit simple, and you could still wrap component usages in blocks, that could then be overwritten.

{# product-list.html.twig #}

<div class="listing">
    {# This block allows the override the entire component. #}
    {% block product_card %}
       <twig:product-card 
          productName="Example product" 
          price="$50,00"
       />
    {% endblock %}
</div>

But when more and more components are introduced, we can run into the problem described by @Phil23

{# product-list.html.twig #}

<twig:listing>
    {# Because listing is now a UX component, the block product_card now is in the scope 
of the "listing" component and can no longer be overwritten on product-list.html.twig level #}
    {% block product_card %}
       <twig:product-card 
          productName="Example product" 
          price="$50,00"
       />
    {% endblock %}
</twig:listing>

[Phil23]

Hey @smnandre, thanks for the open answer.

the goal was mainly to build isolated UI elements, leveraging PHP and Symfony for business logic, security, caching, etc., rather than to offer a full UI composition system.

But wouldn't that be nice? 😃 All these frontend frameworks, like React, Vue, Angular, etc., have gained so much popularity over the years, and have grown into big communities. That has also put a lot of pressure on the platform creators, like us at shopware, to provide solutions that make use of these modern frameworks. That's why we also have a "headless" frontend solution aside from our classic standard storefront that can be built with modern JavaScript frameworks.

But ... we also see a lot of interest in these kinds of "back to the roots" solutions. Less complex tech stacks that make use of native web standards, which are easy to comprehend and maintain. And that is exactly what we would like our standard storefront to be.

Nevertheless, no matter which frontend solution you prefer, we see that the requirement for design systems, composed of atomic UI components, has become the de facto standard for building any kind of larger website or online store.

And honestly, for that kind of layout work, nothing beats Twig's native block inheritance. It's more powerful than we often give it credit for.

Agree 100%. That is the main reason why we are using Twig for our standard storefront, as it is an essential part of our extension system. We even used it in our VueJS administration, by leveraging TwigJS, to offer the same kind of block system. Nevertheless, our admin team is currently moving away from this by offering new solutions that are compatible with native VueJS components, because the mix of Vue and Twig was also very confusing for our community.

But that is the whole point. For a lot of developers, Twig feels old and outdated. And I assume that is why Twig UX has gained so much attention, because also for us, it sounds like a nice move in the right direction to compete with all the other frameworks. And in my opinion, it has to develop further if it wants to stay relevant. I would even go so far as to say that it is an important aspect for the whole PHP ecosystem to stay relevant, as the JS ecosystem keeps growing and growing.

For me, it could have big potential for the Symfony framework as a whole, to serve this "web-native" interest.

That said, I do believe a slot system could work, but only under one condition: once you enter a component using slots, you switch to a 'slots-only' mode. Blocks no longer apply. And vice versa.

But that is exactly what we want to have, right? 😅

Coming back to the problem. I am not a strong PHP developer and not very familiar with the Twig internals, but wouldn't it be possible to still have block nesting within the "slot" component blocks, so the template is composed from the inside out. Every block on first level within the component scope is used to slot the content into the component, but inside those blocks, the nesting of blocks is still possible and they could be accessed from the page scope?

{# navigation.html.twig #}

{% block main_navigation %} {# I am a normal block of navigation.html.twig #}

    {% component Navigation %}
        {% block content %} {# I am a component block and everything inside is passed into the component. #}

            {% block main_navigation_items %} {# I am a normal block of navigation.html.twig #}
                <a class="navigation-item" href="/">Home</a>
                <a class="navigation-item" href="/">Foo</a>
                <a class="navigation-item" href="/">Bar</a>
                <a class="navigation-item" href="/">Baz</a>
            {% endblock %}

            {% block main_navigation_dropdown %} {# I am a normal block of navigation.html.twig #}
                <div class="navigation-dropdown">

                    {% component DropDown %}
                        {% block content %} {# I am a component block. #}

                            {% block main_navigation_dropdown_items %} {# I am a normal block of navigation.html.twig #}
                                <ul>
                                    <li>Foo</li>
                                    <li>Bar</li>
                                    <li>Baz</li>
                                </ul>
                            {% endblock %}

                        {% endblock %}
                    {% endcomponent %}
                </div>
            {% endblock %}
        {% endblock %}
    {% endcomponent %}

{% endblock %}

{# custom-navigation.html.twig #}

{% extends "navigation.html.twig" %}

{% block main_navigation_items %}
    {{ parent() }}

    <a class="navigation-item" href="/">Custom Foo</a>
    <a class="navigation-item" href="/">Custom Bar</a>
{% endblock %}

Wouldn't this work? It is similar to nested blocks today, despite the fact that the first-level blocks inside components are used to pass the content into the component. With this, we wouldn't need to add a new syntax or anything. The code would look very similar to nested block templates as of today. It would be even fine for us if this only works with the Twig syntax.

[smnandre]

Sorry i was 100% certain I answerd you already :(

Blocks, components, Twig, is not something easy, but really i'm very very open to any implementation that would do all this with no BC break.

So -and it's a very genuine invitation- if you have some POC (even not perfect / 100% working) please open some branch / draft and we will iterate on it.

On my side, i've broke every teeth I have on these questions for a year, because of the constraints I explained previously (but i'm far from the best developer around so there is a more-than-probable possibility something can be done 😅 )