Allow blocks to inherit the block types

[bakura10]

Hi,

In the context of a generic "Group" theme block, I think it would be useful to allow a block to inherit the blocks from its parent. For instance, imagine a rich-text section allowing "rich-text", "heading", "button" and "group" theme blocks. We would like to allow grouping only the same theme blocks (and not the full set of blocks).

{%- content_for 'blocks' -%}

{% schema %}
{
  "name": "t:blocks.group.name",
  "blocks": [{ "type": "inherits" }]
}
{% endschema %}

[stephanie-shopify]

Hi @bakura, so i understand the idea better, what is the problem you are trying to solve?

Is it that the block picker is not specific enough for particular blocks? We have block targeting available https://shopify.dev/docs/storefronts/themes/architecture/blocks/theme-blocks#target-specific-blocks

[bakura10]

Hi Stephanie,

I’ve explained briefly in my original message, let me give another try.

Imagine a theme with hundred blocks (which will be what happen for a complex theme), targeting will become needed everywhere.

let’s say we create a Rich text section. This section will only support a subset of blocks (button, paragraph, heading…). This can be achieved in the section itself.

however, we for instance have in some themes a rich text section that support having two columns, so you split the content. Of course we could create a dedicated « rich text column » but if we’re starting to go this way to create dedicated blocks for everything, we won’t end up with 100 theme blocks but probably 200 or 300, which I would like to avoid.

to solve this I think that having a somehow generic « group » block, with a layout setting to let the merchant control the width of it, would be handful. To make this work, we would need to add this group block to the rich text section itself. But the issue is that once we add the group block to the section; then what blocks will be supported for the group block won’t be any longer controlled by the hosting section. As each section will support different type of blocks, this will be a problem.

that’s why I would like that a block could inherit blocks from its parent (so here the group block would only allow the same blocks of the parent section), or alllow in a section schema to override the targets of a child block.

[bakura10]

Here is another use case. We're having a few sections where we want merchants to be able to position content on a grid (either top left, top center, top right, center left... and so on).

To do that, I'm thinking of creating a generic theme block "Positional content" that just have one setting (its position on the grid). However, here as well, the blocks that the positional content should accept depends on the section. I would like to avoid having to create ton of blocks like "image-with-text-overlay-positional-content", "countdown-positional-content"... and so on.

[benjaminsehl]

Great idea.

Similarly, I’m keen to hear what you think about “categories” of types overall. I’ve been feeling like @theme / @app / explicitly naming individual block types is not a great dichotomy.

[bakura10]

A concept of category would be nice, although the use case will probably be quite limited (I'm thinking of something like "text blocks" that would contain blocks like heading, rich text, button...). But I'm not sure we have a lot of other use cases for groups.

[bakura10]

What would be more useful actually @benjaminsehl would be able to create folders in the blocks:

• blocks/slideshow/controls.liquid
• blocks/slideshow/slide.liquid

And allow a consuming section to do that:

blocks: [
  { "type": "@app" }, { "type": "@theme/slideshow" }
]

If we adopt theme blocks, we will have TON of theme. Being able to have the top-level theme blocks that would be kind of the "core" blocks, and nested theme blocks that would be the section-specific would be extremely useful for code maintenance and re-usability.