[LiveComponent] New placeholder macro to generate defer/lazy skeleton

[smnandre]

Q	A
Bug fix?	no
New feature?	yes
License	MIT

When you use defer/lazy component, you can customize the "loading" content in the calling template. But for components that you reuse on multiple pages, it can lead to code duplication.

Moreover, you cannot adapt the size / content depending on the props.

So... introducing the "placeholder" macro.

If you define such macro in your lazy component template, it will be called to generate this temporary content.

{# templates/components/FooBar.html.twig #}

<div {{ attributes }}>

    {# ... #}

    {# your live component code #}

    {# ... #}

</div>


{% macro placeholder(props) %}
    {# This code will only be visible in the "loading" content #}
    <span class="loading-row"></span>
{% endmacro %}

Bonus, you'll get the props of your component as parameters.

So let's say you have a live component which load N comments behind an article.

When you set this prop to your live component, it will be passed to the placeholder macro, allowing you to fill the good amount of space / loading blocs in the HTML

<twig:Comments n="5" />

{# templates/components/Comments.html.twig #}
<div {{ attributes }}
...
</div>

{% macro placeholder(props) %}
    {% for i in 1..props.n %}
        <span class="loading-block"></span>
     {% endfor %}
{% endmacro %}

What do you think ?

[smnandre]

I tried things with blocks (but you'd have to manually "not render it" when not in lazy), with includes (but i wanted to keep code in the same template), so it feel a good balance.

[kbond]

This is nice! Does rendering loading content traditionally take priority over the macro?

[smnandre]

This is nice! Does rendering loading content traditionally take priority over the macro?

Yes, if you pass a loadingTemplate attribute it takes precedence. And the loadingTag is "around" for both cases.

[kbond]

So the primary benefits are:

• not requiring injecting the same loading template for every use
• allows accessing the passed component props

[smnandre]

Exactly and the last one:

• "styling" the block in a single place

It's 100% optional and has no cost obviously :)

[weaverryan]

Seems very sensible. Doing this with blocks, in theory, would be cool - but I totally agree that, in practice, it doesn't seem possible in a nice way.

[weaverryan]

Looks like I missed this one :)

[weaverryan]

Thanks Simon!