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.