Theme block limitations

[stephanie-shopify]

These prompts are just sample questions. Please share your painpoints

• What would stop you from implementing theme blocks?
• What specific use cases do you feel theme blocks do not allow for?
• In what cases would you consider using section defined blocks instead of theme blocks?

[MurmeltierS]

After experimenting with the reference theme, I'd like to share some reflections.

Isolation:
I understand the rationale behind not making the section object accessible within theme blocks, but this restriction has some clear downsides:

• No access to section.index / section.index0. This feature, added not too long ago, allows for functionalities such as lazy loading images starting from the second section onward. This currently cannot be implemented with theme blocks.
• The inability to access section.settings is also a limitation. Although the future direction of theme blocks remains to be seen, there are instances where accessing the section scope could be beneficial, for example, to enable different behaviors of a block based on its section.

Merchant-facing Experience:

• While having all the theme blocks availble as an option is generally nice, I'm concerned that merchants might feel overwhelmed by the extensive list of options. Introducing a feature that allows blocks to suggest recommended sub-blocks, displayed prominently at the beginning of the list, would significantly enhance usability.

These are my initial thoughts - good job @ everyone involved.

[clauderic]

Hey @MurmeltierS, thank you for your feedback!

We are actively considering solutions that will allow merchants to see relevant blocks in the block picker (either with targeting or recommendations). We're also planning on providing access to the section hints to make sure that theme blocks can leverage them too.

On the other hand, we are not currently considering providing access to the settings of ancestors in the Liquid markup of theme blocks.

[MurmeltierS]

@clauderic thx for the context

ps: you're the dndkit guy, right? I suddenly feel a lot more confident in the future of liquid storefronts. lol

[dhruveonmars]

I totally get why section.settings aren't accessible in blocks - because it would be different for different sections, however agree, other values of the section object would be good to see, eg, index, index0, location, and I think these would be consistent and not dependant on any customisations done to a section. Perhaps new liquid options, such as section_index

[stephanie-shopify]

As we design some solutions for surfacing the most relevant blocks to merchants in the picker, 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

[PaulNewton]

Not having sections data will just create another area where {% capture %} parsing kludge has to happen.
The amount of gymnastics caused by black boxing the scope of the {% render %} tag has been an inflexible detriment where we can't keep code in logical files and leads to code duplication; which exacerbates not being able to create actual global variables or custom-objects.
Now add nesting to that inflexibility.

Not having any sort of escape hatches to get that data for the context of the pages logic we are building for is a bad thing and always has been.

[dhruveonmars]

At the moment, I think theme blocks provide far too much flexibility, and not enough control.
I love that you can create something once and can be 100% sure it's consistent everywhere it's used, eg a product card, a product buy button, etc, however I feel like there needs to be some way for theme developers to put some restrictions in place.

For eg, what if instead of only allowing all theme blocks on a section, or 2.0 blocks only, we were able to allow specific theme blocks. Something like:
"blocks": [{ "type": "@theme/sidebar" }, { "type": "@theme/product-card" } for example. That gives theme developers more flexibility in how they build sections/blocks, and gives them some more control of where/how blocks can actually be utilised.

Are there scenarios where you can mix both theme blocks, and 2.0 blocks in a particular section? I'm assuming not.

[thagxt]

A lot of people have mentioned this issue before. But when you understand what Shopify plans to do with themes in the future, you quickly realized why we can't have the limits everyone wants. Shopify wants their AI, Sidekick, to be able to change themes however the merchant wants and asks for. And we all know shop owners like to put things wherever they feel like, and get upset when they can't do something, and the AI isn't going to stop them. So, putting in rules about where you can't put things doesn't really work if you want the AI to be able to do its thing and keep the merchants happy. I think that's the main reason they didn't put this option from the start. However, I completely agree that this approach doesn't make sense and that it will lead to only problems and without any safeguards it will be a disaster.

[dhruveonmars]

AI can and should be able to stop them. I don't think having no rules bodes well for how things can or should be done.
Assuming Sidekick won't work on themes that don't leverage theme blocks then, I'd also assume less update in theme blocks.

Everywhere and everyone I've ever worked with, it's usually for designers/developers/marketers to be putting best practices first and giving advice to merchants who don't know better. Even more-so for merchants who don't have D2C or Ecommerce/Tech backgrounds.

[thagxt]

I'm only speculating here since Shopify hasn't formally revealed their plans. But absolutely, I agree with you.

One of Shopify's strenghts, in my opinion, is that its themes are created by experts in their field. This means there's a safety net in place to avoid ending up with a hot mess, as 95% of merchants aren't exactly web design gurus, and they shouldn't have to be.

Right now, it appears to me that Shopify is focusing and basing their future plans solely on how Dawn works, and how these new feats would make Dawn more extendable and versatile, and they may be overlooking other themes and their needs or how they work; I may be mistaken, but in the last year or two, the majority of the feats they've released have been because Dawn needed them, not because other partners asked for them.

[PaulNewton]

Or possibly an ideal scenario dictating the structure with CSS selectors (discussion)
{ 'allow': '.slide > .image , .image > .text + .button , .slide >.button + .text' },
{ 'disallow': '.button > .image , .text > .image' }

[pbright]

One thing I haven't seen mentioned in other discussions is the reliance on {{ section.settings.product }} in the block presets for the featured product section.

Although this sets each theme block's product field to the product assigned to the section, as far as I can see there is nothing to stop a merchant from removing or changing the product assigned to each theme block. If a merchant accidentally changed the product assigned to the buy buttons in a featured product section, for example, then all of the details would be for a different product than the one added to the cart. This would create a very confusing situation for the customer, merchant, and theme support.

Will there be anyway to prevent this?

A separate but related issue is that currently a merchant can remove a theme block that is essential for other theme blocks in the same container to function correctly. For example, the merchant could remove the buy buttons from a featured product section, while leaving the quantity selector and variant picker in place.

One option here might be to allow specifying required child blocks, so that a purchase form theme block could be defined which can't have the fields necessary for the purchase process removed (while still allowing them to be reordered by the merchant).

[dhruveonmars]

Agreed, not just for a product or collection setting, but the same thing can be said for selecting a colour scheme. We wouldn't typically want a colour scheme to manually need to be changed in several nested blocks just because the top one changed. There would need a new option which would just be 'inherit' or something to that extent. Or a null option.

[stephanie-shopify]

A separate but related issue is that currently a merchant can remove a theme block that is essential for other theme blocks in the same container to function correctly. For example, the merchant could remove the buy buttons from a featured product section, while leaving the quantity selector and variant picker in place.

Static Blocks are one potential solution which is available in the developer preview that may address this. Would love feedback on how this serves your use case and other limitations you may run into https://shopify.dev/docs/storefronts/themes/architecture/blocks/theme-blocks/static-blocks

[pbright]

Static Blocks are one potential solution which is available in the developer preview that may address this. Would love feedback on how this serves your use case and other limitations you may run into https://shopify.dev/docs/storefronts/themes/architecture/blocks/theme-blocks/static-blocks

Hi Stephanie,

While that would work it's quite limited due to the inability to reorder statically rendered blocks.

Take the product info section (everything in .product__info-wrapper) on the product page from the Dawn theme demo for example:
https://theme-dawn-demo.myshopify.com/products/small-convertible-flex-bag-cappuccino

This could be implemented using theme blocks, but many of the items need to be required (price, options, qty etc) so the ability of a merchant to customise this section is greatly limited if statically rendered blocks have to be used.

Say, for example, the merchant wanted to move the price to be below the product options instead of above (which is arguably better for usability if variants have differing prices), or the merchant wanted to insert a text field between any of the required blocks (some help text related to the product options such as a sizing chart, for example). The first isn't possible since the order of the price and product options can't be changed, and while it's been a while since I had a play with the reference theme from what I recall the second wasn't possible either as all of the statically rendered blocks are grouped together in the editor and the non-statically rendered blocks can't be dragged in between them.

It would be great merchants could make these kind of minor tweaks without needing to edit any code, so that they continue to get the benefit of automatic theme updates.

[PaulNewton]

One option here might be to allow specifying required child blocks

I haven't played with this in a while either so 💨untested spitball for this bikeshed to address multiple factors.
Two blocks:

1. "Standard Product Form" a ?preset? block that has within it a static product-form so limited configurability; except above/around/below that block per schema
2. "Configurable Product Form"* a free-for-all block but comes with a very obtrusive "Design Policy" warning(or it's even it's own block cuz why not).

Merchant still able to make a fundamental change but starting point has more guardrails for most users.

the reliance on {{ section.settings.product }} in the block presets for the featured product section... there is nothing to stop a merchant from removing or changing the product assigned to each theme block
a merchant can remove a theme block that is essential for other theme blocks in the same container to function correctly

Isn't the issue the same for merchants that don't know they broke it and those who know exactly what they are doing:
even if a features context scoping finally gives us the properties we want for error handling themes can't communicate possibly bad states easily and effectively.
We want bad states to be impossible, but making bad states impossible is impossible so we must scream 🤪.

Usage

For example, the merchant could remove the buy buttons from a featured product section, while leaving the quantity selector and variant picker in place.

Counter point ,
Merchants want and do remove buy buttons all the time such as for apps,custom-liquid blocks, file-based theme customizations , design previews, mockups.
Seemingly almost always with some HTML/JS to be the trigger for apps/customizations like pre-orders, contact-forms, ab-testing, or an app, service or api, and rarely without some agenda
So any required logic,, hand made or auto-disabling, of product-form related blocks creates it's own confusing dead ends.

But are both sides, by accident or on purpose, non-normative enough that anyone making such changes should be punished with an non working product form because they should "just know"™ what is or is not typical 🤔 .

Aren't merchants who do this but can't figure out they broke things just ineligible for a support policy and on their own to fix their lack of understanding /s.
Buuut really who is gonna say "no support", the theme still has to be looked at to even validate such ineligibility. this a the type of high level detection|linting for broken theme behavior shopify should be building public tools for to kill off that whole segment of support

Either way will theme devs get punished creating bespoke error handling for block existence or block combinatorics even IF we can read all the blocks/settings nearby. or bespoke display logic such as with "separator" blocks that split content among different areas

Effect on design homogeneity

Block error handling whether removal , disabling, reorderability, or existence of siblings, has created a design doldrum among aesthetics in themes AND across themes.
Since any block can be anywhere theme designers are forced to give most blocks lavish padding/margin, or do the oh so fun work of creating compounding CSS sibling-selectors (pain to customize/maintain) ;i.e. .price + .qty { float: right; } , .qty + .addtocart { margin-top: .5rem; }

🐲 🗺️ Now add nestable blocks to this mix and this sameness among blocks quickly becomes a de-facto requirement because there's no way to support all the possible combinations of ordering AND nesting , and any theme developer has to assume their design "system" either covers enough cases or just hope it's bullet proof.

With that I'd argue more in favor of static sections being inflexible for everyone; as long as we can put them in OTHER blocks 🤔?
So theme designers can be very specific in art direction, and theme developers support a saner range of error handling.

Meta - design policy?

we can bikeshed all day for technical solutions for better design intent, or to avoid bad states, but this seems like it's more about branching paths for merchants :

• static aka standard(predefined?[2]) combinations = standard and supported as it is explicitly the theme-designers intent
• non-static aka undefined-blocks[3] combinations = free for all use of nested blocks, advanced customization and not supported because of compounding[1] factors
• static = minor changes: settings, liquid-settings, custom-css or custom-liquid blocks at predefined locations.
• non-static = major changes: block order|nesting combinatorics, app-blocks, ???

A pattern I see in these new features is once a merchant starts configuring them there is going to be boundary where they are in full customization territory, no file modification required.
So there needs to be a better way making users aware they must take on more responsibility for compounding configuration customization choices.
And there is no way for theme developers to dynamically create such onboarding; unless ignoring the suggestion to not modify the theme preview in the visual theme editor.

[1] I'm loathe to say "Custom Product Form" or custom-blocks in this context, as that should be left to actual custom blocks the merchant adds to a theme, or actual code in features like custom-liquid or custom-css as a clear boundary.
[2] I want to say exponential factors but that's exponentially harder to make an example for either os2.0 or theme-blocks.
[3] words are hard

[super-morris]

Hey, not 100% sure if I am right here, but why would you stop us from mixing theme blocks with other local blocks?
We are a no-code, low code app builder for shopify and we need to add blocks via asset api for custom apps to simulate app blocks. however it does not make any sense to us, to not allow theme blocks the same way app blocks are build?

theme blocks should be allowed everywhere app blocks are allowed

[super-morris]

Here is our specific use-case in more detail:
As one very important part of our product we offer our users a UI builder to build custom UI components.

Shopify wants to push blocks to have clean components that don't interfere with the theme directly. Blocks are a good idea, as they allow customers to have reusable components and place and configure their UI elements nicely and comfortable.

Apps that build dynamic UI components are still able to use the asset api. As at the moment there is no other way to build dynamic frontend elements via apps them self. However shopify is right and even with the asset api, apps should not change the content of a theme directly. This could break the theme, once the app is uninstalled (specially as shopify still does not allow to remove the code via the asset api once the app is uninstalled).

Theme blocks would be the perfect solution for apps and merchants to build custom dynamic content that doesn't directly interfere with the theme. But more importantly it gives the users the possibility to have custom clean reusable blocks in their UI.

Users will often need to add UI components to existing sections. Theme developer can also decide if app blocks are allowed within a section and now also can decide whether theme blocks are allowed or not.

I don't see a valid reason to always restrict to combine theme blocks with other local blocks. These only takes away flexibility and functionality. Moreover why should a private theme block have any less possibility to be combined with local theme blocks than an app block is allowed to? And if the theme developer still wants to restrict it, he can disallow the use of theme blocks in the section anyway.

Please allow theme blocks with local blocks, the same way app blocks are allowed!

However while theme blocks should be used the same way as app blocks are, I would also allow apps to build, add and remove app blocks dynamically via the admin api. Many use-cases for apps need dynamic components and should not need the asset api for that.

[super-morris]

and why are theme blocks not allowed in the thank you and order confirmation page?

[bakura10]

Sorry if this has already been mentioned (I might have myself, sorry about that), but mixing theme block and section block should really be needed, and content_for should allow to have a different "root". For instance, in the context of a slideshow, I do not feel it is correct to create a specific slide block that would be only used in the context of this section. This will just pollute the theme blocks and make it hard to understand how a given block can be used.

Ideally, a slideshow section should be able to work like this:

<x-slideshow>
  <div class="slides">
    {%- assign slides = section.blocks | where: 'type', 'slide' -%}

    {%- for slide in slides -%}
      <div>
        {%- content_for 'blocks', root: slide -%}
      </div>
    {%- endfor -%}
  </div>
</x-slideshow>

{% schema %}
{
  "name": "Slideshow",
  "blocks": [
    {
      "type": "slide",
      "name": "Slide",
      "settings": [
        {
          "type": "image_picker",
          "id": "image",
          "label": "Title"
        }
      ],
      "blocks": [
        { "type": "heading" },
        { "type": "button" },
      ]
    },
    {
      "type": "controls",
      "name": "Controls"
    }
  ]
}
{% endschema %}

[vi-]

Ran into the same challenge. I am customising a theme for a client and they want about 4-5 existing sections to be extended to allow for a up to 2 stickers (absolutely positioned in relation to the section). The sections already have their own unique blocks, and theme blocks initially seemed like a perfect feature to accomplish this until I ran into Theme blocks and section-defined blocks can not be used together error.
It seems that not allowing to mix section scoped blocks with theme blocks by choice is moving towards deprecating section blocks in favour of theme blocks. However, there will always be scenarios where a section only requires 95% of the functionality available in a defined theme block, or requires all 100% but wants to extend it.

[Made4Uo]

I agree. We also run issues when developing a theme for a client. Theme blocks and section blocks should be nice if they can be use together. We just need to make sure that the block names are unique. I also notice that the block icons are defaulted to this text icon. It only happens after I save the theme.

I also wish we can also control the blocks. This would be nice if we try to place the same block on multiple areas of the section

{% content_for "block", type: "_title", id: "id" , custom_control: custom %}

Inside the theme block you can call the custom_control
{% case custom_control %} {% when 'option_1' %} render this configuration on top of the section... {% when 'option_2' %} render this another configuration bottom of the section... {% endcase %}

Limitations:

• Theme blocks and section blocks cannot be use together
• No custom control flow
• Blocks cannot be added more than one in the same section

Do you guys recommended to use this theme block right now? Or wait until fixes are done

[indextwo]

I know this is an old thread now, but I've just come across a limitation of theme blocks that's particularly irksome in my use-case: I can't access the block.settings from the parent.

Let's say I have a section that only allows one type of private block: _form-field. I can output those blocks no problem:

{% content_for 'blocks' %}

I can also use the for loop to capture the content and do something cludgy with it if I need to:

for block in section.blocks
    capture block_content
        render block
    endcapture
endfor

But for some reason I can't access the settings WITHIN that block:

for block in section.blocks
    assign field_type = block.settings.field_type
    # This gives me nothing
endfor

I can access block.type, which only ever returns @theme, but that's about it. Even block.name gives me nothing.

As it is, I'm having to work some kind of major Rube Goldberg machine with render and some JS to try to fudge a solution at the moment.

[CarloStokMnl]

I'm encountering this also as you can't get the number of blocks inside of it like in the section.blocks | size. That should be allowed as this is kinda limiting if you want to target something based on the number of sub-blocks