Theme Dev Experience

[stephanie-shopify]

• What went well in your experience with theme blocks?
• Did you experience any challenges when recreating your sections with theme blocks? What were they?
• How would you plan your migration to theme blocks?
• What would improve the experience of building with theme blocks?

[AlfalfaAnne]

Just playing around with creating some new blocks and seeing how to migrate from blocks hardcoded in sections and I am in LOVE with how you're referencing the "type" name as the block name. It allows the settings to carry over soooo seamlessly. I made a little video of converting a Dawn section into using blocks (just for the button block to test and for myself as a guide haha) and it's great. https://share.zight.com/eDuePw7B

I do have a question though - is there going to be a way to use the enabled_on/ disabled_on property? It seems like at the moment, since you can't hardcode theme blocks nested in a theme block, that means you have to give access to every single block wherever "@theme" is used. And since you can't combine it with hardcoded blocks, it's almost too much of a free-for-all.

So just like you might want to only use certain sections in a header/footer, it would be great to limit certain blocks in specific sections. eg. maybe it makes sense to only have a countdown timer block in certain instances (for example).

eg.
"enabled_on": {
"sections": ["image-with-text", "video-with-text"]
}

Hope that makes sense - I am SO EXCITED for this! 🎉

[bakura10]

I'm not a fan of enabled_on/disabled_on at the block level. Similar to web-components, blocks should be generic code that do not know about where they are embedded on. It is the responsibility of the section to know which blocks can make sense in a specific section.

Compare this:

{% schema %}
{
  "name": "Heading",
  "enabled_on": ["rich-text", "slideshow", ...]
}
{% endschema %}

Here there is an explicit coupling on something that is supposed to be generic (a heading) with section. If you have 30 sections, you will end up with a very long name of section names. If you remove a section or change its name, it also forces you to keep in sync all the blocks.

While this move the responsibility to the consumer (the section):

{
   "section": "Rich text",
   "blocks": [{"type": "@theme/heading"}]
}

[bakura10]

Similarily, we should also be able at a section level to limit the number of time a given block can be used. Typically, in our section Rich text we want the merchant to have either one or two columns (but not more, due to how the section is design):

{
   "section": "Rich text",
   "blocks": [
       {
          "type": "@theme/column",
          "limit": 2
       }
   ]
}

I understand that Shopify might want to give the maximum flexibility to merchants, but one reasons our theme have been successful is exactly because they were opinionated in the design, and that we did not let them merchant shoot themselves in the foot by giving them boundaries. From a support perspective, having limits is also extremely important, otherwise we are opening the Pandora box of merchants doing crazy stuff, and reaching at support that the theme breaks.

[visnaut]

I agree with many of the above ideas. I think it's table-stakes to be able to:

1. Limit how many blocks can appear in a given container.
2. Limit which blocks can appear in a given container. Both at the:
   • Theme Block level
     • à la sections' enabled_on, and disabled_on schema.
   • Container Level (i.e.: Section or Theme Blocks that allow nesting)
     • This should also allow for inclusive and exclusive logic, such as "only allow these kinds of blocks" or "allow all except these kinds of blocks"

I know the argument against all of these might be "well, if you're looking to potentially limit theme blocks to only one section, why not just use section blocks?". My counter-point would be that section blocks can't be nested, but nesting is desirable in many contexts.

Another thought here is that you may have a Section (or Theme Block for that matter) that may function like a slideshow, and it would be beneficial for a theme dev to define that such a block container can only contain other block containers, as opposed to primitives (such as text, image, etc.) as root level blocks.

We are actively working on solutions around targeting theme blocks and will share more details in the coming months!

Thank you, @clauderic! That's reassuring, and I encourage you to share proposed approaches here!

[VedranCOI]

I second above requests for limit and control and i agree with @bakura10 that the responsibility of allowing blocks should be on the section level.

Which i have noticed now when playing around in reference theme, you are able to add a Featured product block on homepage and that block will contain Product medias as they are added in presets. At the same time product medias block are not added to the theme scope and its not available to be added once you delete it from the section.

[stephanie-shopify]

As we design some solutions, we would love to get some input from you all about some use cases you are considering around targeting. Please share your thoughts here: #20

[bakura10]

Hi,

I'm cross-posting the message I shared on Slack:

I had a look at the new theme blocks feature, this is basically component in Liquid, which is a great thing. However, there are a few problems that make them nearly unusable for us in theme context.

1. The fact that a section can either support local blocks OR theme blocks is a huge limitation. We often have sections that have custom blocks that only makes sense in the context of this section (like, this is the case for most of our sections).

2. As soon as you create a theme block, it seems to become available in all sections supporting theme blocks. This does not make any sense, and we can't architecture and design our sections (often specialized sections) to support all kind of blocks. We need to be able to select which theme blocks can be supported in a given section.

3. Inability to extend theme blocks: in our theme, we often have a lot of duplicated settings across section. For instance an icon block defining an image, a width, and a mobile width (this is what I would call the "minimum set of settings"). Then, depending on the section, we have extra settings to adapt this block to this section context. For instance, a position setting. I think we can go around this though by creating two types of blocks, like icon and positioned_icon

But this use case really needs to be taken into account.

What is sure though is that we need to be able to mix it with section-level blocks, AND be able to filter which one we want:

{
  "blocks": [
    {
      "type": "@theme/icon"
    },
    {
      "type": "@theme/text"
    },
    {
      "type": "section_block",
      "name": "Section block",
      "settings": []
    }
  ]
}

In its current design, we won't be able to adopt theme blocks, at least not in our themes.

[bakura10]

Just to give you a bit more visual context, here is for instance the slideshow of Impact:

Each slide has content, but also slide-specific extra setting, such as the position of the content, and the background color.

I would like to be able to mix the two, and doing something like this:

"blocks": [
  {
    "type": "slide",
    "blocks": [
        {
            "type": "@theme/subheading"
        },
        {
            "type": "@theme/heading"
        },
        {
            "type": "@theme/button"
        }
    ]
    "settings": [
        {
           "type": "select",
           "id": "content_position"
        },
         {
           "type": "color_background",
           "id": "background"
        }
    ]
  }
]

[bakura10]

This {% content_for "blocks" %} is also a bit weird and inconsistent with app blocks. The fact it is a string does not really allow the slide use case. What if it would work like this instead:

{% for slide in section.blocks %}
   <div class="slide" style="background: {{ slide.settings.background }}; place-items: {{ slide.settings.content_position }}">
      {% for block in slide.blocks %}
         {% if block.type contains '@theme' %}
            {% render block %}
         {% else %}
            // Section managed blocks
         {% endif %}
      {% endfor %}
   </div>
{% endfor %}

The contains is not really nice, but some better alternative could be found, like block.renderable (that would also work for both app and theme blocks, for instance).

[clauderic]

Thanks for providing these examples and additional context @bakura10.

As our teams internally have been working on adopting theme blocks, one pattern we have seen emerge is that we see much fewer use-cases for bespoke sections and settings. A lot of the layout capabilities can be accomplished through composition of generic theme blocks that have generic settings, and providing presets that assemble theme blocks into a variety of different layouts and configurations.

While this doesn't entirely remove the need for bespoke sections and blocks, we anticipate our future themes to have drastically less bespoke sections than in the past, and that we will be able to replace them with presets of more generic sections and nested blocks.

We're planning on making a lot of investments to theme blocks this year, and for the time being we are not planning to bring these same capabilities to section-defined blocks, so we hope that we can smooth out any of the pain points in adopting theme blocks.

[bakura10]

@clauderic , unfortunately when I see the designs that I have to develop, I'm indeed seeing composition, but it's not that easy... If you want you can reach me on Slack, I can give you some visual example of the new theme I'm working on.

[clauderic]

The {% content_for "blocks" %} tag will provide the platform with strong guarantees that blocks are rendered in the order that merchants have positioned them in the theme editor, and without conditionals. This will allow us to bring more optimistic interactivity in the theme editor, such as live reordering of blocks and drag and drop.

While we strongly encourage developers to use the {% content_for "blocks" %} tag to provide merchants with the best experience in the theme editor, there may still be cases where you want to manually iterate over the blocks using a for loop, which is something you can do as so:

{% for nested_block in block.blocks %}
    {% render nested_block %}
{% endfor %}

In the example you shared above, the parent that is rendering the slides is reading the settings of its child block – this is not something we are planning on allowing. However you could use a for loop to render nested blocks in a certain way based on the parent settings:

{% assign parent = block %}

{% for nested_block in parent.blocks %}
   <div data-foo="parent.settings.bar">
      {% render nested_block %}
   </div>
{% endfor %}