Allow to render theme blocks as snippet

[bakura10]

I like to think blocks as "components". They should be re-usable but also included in the rest of the code.

For instance, in our next theme we have a subheading that is styled in a very specific way, and require different configuration. While trying to migrate this to theme blocks, I therefore created a new theme block with the parameter:

{%- render 'subheading', content: block.settings.text, has_icon: block.settings.has_icon -%}

{% schema %}
{
  "name": "Subheading",
  "settings": [
    {
      "type": "inline_richtext",
      "id": "text",
      "label": "Subheading",
      "default": "Subheading"
    },
    {
      "type": "checkbox",
      "id": "has_icon",
      "label": "Has icon"
    }
  ]
}
{% endschema %}

The reason I need to have a snippet is because I have some other sections that also require showing a subheading, but where the subheading is not rendered inside the context of the block.

I happen to actually have this on a lot of different elements, which ends up having each component duplicated twice: once as a block, and once as a snippet, where the block just include the snippet.

I would like to actually be able to also render an app block, and passing it parameters that would be transformed as options:

{%- render '@theme/subheading', content: 'Content', has_icon: true -%}

This way, the snippet content can be integrated into the block.

If a user try to pass an option that does not exist in the schema, then it should simply be ignored:

{%- render '@theme/subheading', does_not_exit: 'Foo' -%}

// In blocks/subheading.liquid:

{{ does_not_exist }} <= Return nothing, because does_not_exist is not part of the schema settings

It might be useful though to have extra options to configure how a block will render, without exposing it visually to the theme editor. For instance, a balance_text option. We might want to use it when rendering the block, but not show it in the editor:

{%- render '@theme/subheading', balance_text: true -%}

We could eventually think of "hidden" settings:

{% schema %}
{
  "name": "Subheading",
  "settings": [
    ...
    {
       "type": "checkbox",
       "id": "balance_text",
       "label": "Balance text",
       "editable": false <= would hide it from TE, but still allows to pass as a parameter
  ]
}
{% endschema %}

I can see this as a great way to actually self-document those blocks. Until now, all of my snippets included a doc with the supported parameters that a dev can use:

{%- comment -%}
----------------------------------------------------------------------------------------------------------------------
SUBHEADING COMPONENT
----------------------------------------------------------------------------------------------------------------------

This snippet generate a subheading badge, with the specified icon defined in theme settings. The subheading badge
is typically used in section header, or inside some sections.

To use only the subheading typography setting without all the badge infrastructure, use the "subheading" class instead.

********************************************
Supported variables
********************************************

* content: the text content to show
* has_icon: if to true an icon is added before the content
{%- endcomment -%}

But it is very easy to forgot adding a documentation when we add/remove option, so having this move to the list of settings make it more explicit.

[t-kelly]

@bakura10 I was thinking of almost the same thing this weekend until a teammate pointed this thread out. Thanks for sharing!

We could eventually think of "hidden" settings:

👍🏻 IMO this is key for progress of reusable components across lots of projects. All configurations for a component should be available to a developer working with the code, and they should be able to cherry pick which of those configurations they want to expose in the editor. It's currently possible to do this with snippets via params as the developer configuration interface and then cherry picking from those params and setting their values to global, section, or block settings.

I can see this as a great way to actually self-document those blocks. Until now, all of my snippets included a doc with the supported parameters that a dev can use

💯 Yessss the schema json is already well structured to provide all the documentation needed for a component. Pair that with moving the schema to the top of the file so that the file starts with variable declarations and you have a nice summary of what variables the components is working with.

Also super easy to pull this JSON with a script and automatically generate some nice docs with it.

The reason I need to have a snippet is because I have some other sections that also require showing a subheading, but where the subheading is not rendered inside the context of the block.

I can't help but feel a simpler future here would be to make blocks capable of doing everything you would otherwise be doing with snippets.

Why can your subheader snippets not become blocks? With the use of presets you could make sure their initial state is rendered the same way they currently do with snippets (especially if we get hidden settings ^^)

[bakura10]

Why can your subheader snippets not become blocks? With the use of presets you could make sure their initial state is rendered the same way they currently do with snippets (especially if we get hidden settings ^^)

Great question. Simply because I don't want to move everything to block. In the case of the subheading in our new theme, we are for instance using it inside product card for labels, so we need to render them in the Liquid code.

Same for more higher level section. Let's take our blog post heading in Impact for instance:

That's a typical example where I don't want the merchant to have to drag & drop ton of block to re-create this. They should just be able to have a "Blog banner" section with everything pre-configured. I really think this is a mistake to believe merchant want an absolute control on everything. Merchant has, for most of them, zero design knowledge, and don't want to spend weeks on drag and drop block.
And here we have a subheading that would require to be render using a snippet (and hence requiring this duplicate of the same block as snippet and block).

There are definitely big overlap in snippet and blocks in this new architecture, and some work should be done to somehow merge them: a snippet should just be used for some reusable content that should never be exposed in the theme editor, while blocks could be used for theme editor AND in a render tag.