Idea of a new stack syntax for twig #4185

Nayte91 · 2024-08-09T09:35:08Z

Nayte91
Aug 9, 2024

Hello,
I primarily submitted an idea on the asset mapper project, but now that I unzoomed my idea a bit, I would like to propose here a new version; note that everything about implementation, names, etc.. Are not the point, I'm sure of anything!

Let's think about a stack portal in twig syntax. In my use cases, it can be useful for CSS, modals, and scripts.
Let's set up an example :

{# foo.html.twig #}
<html>
    <head>
        <link rel="stylesheet" href="{{ asset('styles/globals.css') }}" />
        <link rel="stylesheet" href="{{ asset('styles/atoms/title.css') }}" />
        <link rel="stylesheet" href="{{ asset('styles/molecules/blog_post.css') }}" />
    </head>

    <body>
        <header>My header</header>
        <main>
            {% include 'atoms/title.html.twig' with {pageName: 'my awesome blog'} only %}
    
            {% for post in posts %}
                {% include 'molecules/blog_post.html.twig' with {post} only %}
            {% endfor %}
        </main>
        <footer>My footer</footer>
    </body>
</html>

At this point, we don't care about what is included; What I see is that in my layout, I have to know which blocks will be used in this very page (in this simple case: title and blogpost), and to accordingly import the CSS files.

So I may want to defer the CSS loading in my blocks? ..But as a <link> tag is not meant to exist in the body, I would like to use a {% block styles %} syntax. ..But to achieve, I need to extends my foo template. ..And if I succeed at it, if I have 10 blog posts, I will include 10 times the template, and so import 10 times the CSS!

So, let's welcome a new {% stack %} syntax:

{# foo.html.twig #}
<html>
<head>
    <link rel="stylesheet" href="{{ asset('styles/globals.css') }}" />
    {% stack styles %}
</head>

<body>
<header>My header</header>
<main>
    {% include 'atoms/title.html.twig' with {pageName: 'my awesome blog'} only %}

    {% for post in posts %}
        {% include 'molecules/blog_post.html.twig' with {post} only %}
    {% endfor %}
</main>
<footer>My footer</footer>
{% stack modals %}
</body>
</html>

{# atoms/title.html.twig #}
{% stack in styles %}
    <link rel="stylesheet" href="{{ asset('styles/atoms/title.css') }}" />
{% endstack %}

<h1 class="page-title">{{ pageName }}</h1>

{# molecules/blog_post.html.twig #}
{% stack in styles %}
    <link rel="stylesheet" href="{{ asset('styles/molecules/blog_post.css') }}" />
{% endstack %}

<article class="blogpost">
    <h2>{{ blog.title }}</h2>
    <p>{{ blog.heading }}</p>
    <div>
        <button type="button">delete</button>
    </div>
</article>

{% stack in modals %}
    <dialog id="delete-modal">
        <p>Are you sure you want to delete?</p>
        <button type="button" class="red">delete</button>
        <button type="button" class="grey" autofocus>cancel</button>
    </dialog>
{% endstack %}

{% stack in scripts %}
    <script src="delete_modal.js"></script>
{% endstack %}

Used like this, stack has 2 superpowers:

it teleports the content at another part of the DOM, wherever the stack out is, without observing template extentions,
it manages duplication of contents when stacking out, without use of parent(), append(), 'if foo.css exists, ..'.

With both, you can create great components without having to think about how to connect them on your exterior twig files; you just write your component, and when the page is generated, everything will work out of the box.

Obviously useful for CSS for those who are asset-mapping/not webpacking.
Teleportation is very convenient for modals, as to not mess-up the display, you may want your modals to be at the end of <body>, as a direct & last children.
Note that for JS, stimulus is used quite like the stack syntax as it teleports out the script in a controller, and if you need 0 it doesn't load, or if you need 10 times it will plug for each accordingly!
It's another important stepping stone for a component based architecture, pairing with atomic design; When FabPot asked what could be good for Twig4, I answered "anything that goes to the component first philosophy": aaand that's one. For example, if you use a lot of twig or live components, following which page needs a style or a modal becomes very hard.
As I thought only about CSS before, I felt like it was asset-mapper's responsibility to avoid <style> duplication, but when working with modals, it appears clearly that it should be a twig new feature, that you will be able to plug with asset-mapper/importmap/twig components/live components/web components/stimulus/early hints/whatever.
Talking about other worlds, I worked a bit with NextJS and for each component you design, you import the partial CSS file in it, and the framework compiles the partials out (CSS modules). But for rendering a modal, this is a pain; a portal react function exists, but it is very hard to use along with modal refs and to keep elegant. Twig's stack would do better for both.

I can imagine that if no stacking out directive is found, the stacking in is warped out and a warning is emitted, but I can't think of all the implementation details.

Thank you in advance for your time for reading me, and sorry in advance if this is trivial or non-sense.

stof · 2024-08-09T19:12:12Z

stof
Aug 9, 2024
Collaborator

This teleportation id probably impossible to implement in the current architecture of Twig though.

Side note, modals based on <dialog> don't need to be added at the end of the body, as opening them brings them in the top-layer

1 reply

Nayte91 Aug 18, 2024
Author

Side note: Fair point!

I would reply that nesting a <form> inside a <form> is forbidden in HTML5, and therefor warping out a modal with a form inside still be very useful;
An example can be the Live component's "Product Form + Category Modal" pattern where you actually can't render a Category form with Symfony Form because it will be inside the Product form, so you have to render and submitting it "by hand".

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Idea of a new stack syntax for twig #4185

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 1 comment 1 reply

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Select a reply

Idea of a new stack syntax for twig #4185

Nayte91 Aug 9, 2024

Replies: 1 comment · 1 reply

stof Aug 9, 2024 Collaborator

Nayte91 Aug 18, 2024 Author

Nayte91
Aug 9, 2024

Replies: 1 comment 1 reply

stof
Aug 9, 2024
Collaborator

Nayte91 Aug 18, 2024
Author