Improve readability of slotted content in snippets

[t-kelly]

👋🏻

I like building compositions from primitives, e.g. a simple text and image section can be quickly thrown together right now in Liquid like:

{% capture content %}
  {% render 'element.text', as:'h2', variant: 'heading-xl', slot: 'Welcome to composable Liquid theme components' %}
  {% render 'element.text', variant: 'rte', slot: '<p>You can compose consistent, high-quality storefronts using well-engineered Liquid components</p>'  %}
{% endcapture %}

{% capture content_stack %}
  {% render 'layout.stack', gap: 'md', slot: content %}
{% endcapture %}

{% capture columns %}
  {% render 'element.image' %}
  {{ content_stack }}
{% endcapture %}

{% capture grid %}
  {% render 'layout.grid', columns_xs: 1, columns_md: 2, gap: 'lg', slot: columns %}
{% endcapture %}

{% render 'layout.section', slot: grid %}

This approach works, but I'm sure we can all agree the syntax is 💩

It would be great if snippets came with a default slot tag, so I could instead write something like this:

{% render 'layout.section' %}
  {% render 'layout.grid', columns_xs: 1, columns_md: 2, gap: 'lg' %}
    {% render 'element.image', img: section.settings.image %}
    {% render 'layout.stack', gap: 'md' %}
      {% render 'element.text', as:'h2', variant: 'heading-xl' %}
        Welcome to composable theme components
      {% endrender %}
      {% render 'element.text', variant: 'rte' %}
        <p>You can compose consistent, high-quality storefronts using well-composed Liquid components</p>
        <a href="#">Click here to learn more</a>
      {% endrender %}
    {% endrender %}
  {% endrender %}  
{% endrender %}

where layout.stack.liquid:

<div class="flex flex-col">{{ children }}</div>

and element.text.liquid:

<{{ as }}>{{ children }}</{{ as }}>

However, from my conversations with @karreiro and @charlespwd, adding an {% endrender %} tag would be a complex and potentially breaking change. We already have other way's of rendering snippets, ie. {% include %}, so what's one more way, right?

Following in suit with {%- ... -%} and {% # ... %} symbol identifiers that have already been introduced, I propose a new tag that emulates an existing open and close pattern most devs are already familiar with,
{%< ... >%}...{%</ ... >%}:

{%< 'layout.section' >%}
  {%< 'layout.grid', columns_xs: 1, columns_md: 2, gap: 'lg' >%}
    {%< 'element.image', img: section.settings.image >%}
    {%< 'layout.stack', gap: 'md' >%}
      {%< 'element.text', as:'h2', variant: 'heading-xl' >%}
        Welcome to composable theme components
      {%</ 'element.text' >%}
      {%< 'element.text', variant: 'rte' >%}
        <p>You can compose consistent, high-quality storefronts using well-composed Liquid components</p>
      {%</ 'element.text' >%}
      {%< 'element.button', text: 'Learn more' >%}
    {%</ 'layout.stack' >%}
  {%</ 'layout.grid' >%}  
{%</ 'layout.section' >%}

I'm not at all married to this specific proposal, but at least let's use it to kickstart some creative thinking?

Why don't I just use slots made possible via theme blocks and {% content_for "block" %}?

Short version -- IMO the theme editor shouldn't be a requirement to make slotting + code-reuse possible in Liquid. It should remain a progressive enhancement that selectively exposes points of configurability in the editor.

1. I want to build sections and deal with the theme editor layer later. Why do I need to wrangle a ton of JSON configs to just render something on the page. That's a ton of extra work that I don't need for a first prototype. Let me deal with breaking things into blocks later.

2. I want to have full control when I'm crafting my theme editor experience. I don't want to expose layout.section, layout.grid, and layout.stack as blocks -- I don't think my customers using the editor will care much about those and they'll just add complexity where it's not needed. I'd rather just add a few settings at the section level.

sections/image-with-text.liquid

{%< 'layout.section', padding: section.setting.padding >%}
  {%< 'layout.grid', columns_xs: 1, columns_md: 2, gap: 'lg' >%}
    {% content_for: 'block', type: 'image' %}
    {%< 'layout.stack', gap: 'md' >%}
      {% content_for: 'blocks' %}
    {%</ 'layout.stack' >%}
  {%</ 'layout.grid' >%}  
{%</ 'layout.section' >%}

blocks/image.liquid

{%< 'element.image', img: block.settings.image >%}

blocks/text.liquid

{%< 'element.text', as: block.settings.element, variant: block.settings.variant >%}
  {{ block.settings.text }}
{%</ 'element.text' >%}

blocks/button.liquid

{%< 'element.button', text: block.settings.text >%}

Related issues:

• Request for improvements: Liquid slot tag to render contents in predefined places #1854
• Add a way to use slots / render children in snippets #1829
• [Proposal] Args for render block #1565

[sadsciencee]

there are some solid existing solutions for these pain points:

1. dave warrington's new packages enables composable section schemas. using these packages to implement a composition pattern will significantly reduce time spent on json config

in a pinch, you can always generate a schema with ai or make a static prototype with plain html

2. blocks can be hidden from the theme customizer by adding an underscore to the filename

maybe im just liquid-brained, but i actually prefer the {% capture %} example here? proposed syntax feels too verbose

[jg-rp]

How about "semantic tags", analogous to semantic elements in HTML? I'm wary of excessive decomposition, so I've flattened "elements" from the example above here.

{% section %}
  {% layout 'grid', columns_xs: 1, columns_md: 2, gap: 'lg' %}
    {% render 'image', img: section.settings.image %}
    {% layout 'stack', gap: 'md' %}
      <h2>Welcome to composable theme components</h2>
      <p>You can compose consistent, high-quality storefronts using well-composed Liquid components</p>
      <a href="#">Click here to learn more</a>
    {% endlayout %}
  {% endlayout %}  
{% endsection %}

Each semantic tag is akin to a block-level render tag, just with different conventions for how to find/load the target partial template. As above, blocks are implicitly rendered and captured from the bottom up, and the result of each render is passed to the parent snippet using a reserved name, like children. Other options for children might be block or markup.

A catch-all {% component %} block tag would probably be necessary. Without semantic meaning, this would be analogous to a <div> tag in HTML.

While such tags and conventions make sense for Shopify's platform, these concepts might not translate well to other uses of Liquid. So, at most, I believe that a single, general purpose block-level render tag should be included in Liquid. Leaving it up to developers to extend it for their own semantic tags an define their own conventions.