[Best practices] What is the point of sections now ?

[TeamDijon]

As Shopify continues to evolve with the introduction of theme blocks, I've been revisiting the traditional role of sections within our themes. Historically, sections served as the foundational elements of Shopify themes, offering specific markup, data, and functionality tailored to various needs. However, theme blocks appear to be shifting the paradigm.

In my own work with Shopify 2.0, I've adopted a minimalist approach to sections, using them primarily as a "markup" base for injecting generic section blocks contained in snippets shared across all my "markup" sections. Then, the sections were created from the section using the presets schema property. Only exception were the unique sections, such as header and footer.

Of course, in order to be backward compatible with older stores, sections will stay.

Nonetheless, I can clearly see theme development tend towards a one-liner ({% content_for 'blocks' %}) monolithic section alongside some schema to handle the different presets.

This leads to several questions :

• The Role of Sections: With theme blocks becoming the centerpiece of theme development, what intrinsic value do sections hold, if any?
• Theme blocks role in theme architecture: Given the advancements in dynamic references and block nesting capabilities, are we moving towards a more unified, block-centric approach that could render traditional sections (and even snippets at some degree) obsolete ?
• Granularity and Functionality: What level of granularity should theme blocks aim for to optimize the merchant experience? Is there a need to distinguish between "layout" and "functionality" blocks in the future?

This is quite philosophical at this point but with this new way of doing comes new practices and I'm curious how you plan to go developing with the theme blocks ?

[t-kelly]

I would extend your point even further and ask what's the point of templates and layouts, too!

The way I see it is that over the years, Shopify has been introducing composability to the merchant via defining certain scopes of a website:

• Layer 1: Layout Files + config/settings_schema.json -- this was the first level of configuration that is available across the entire site. It was seen pretty early on that having all settings here got pretty wild.

• Layer 2. Template JSON files -- this is the page specific editor config that was introduced to make 'sections everywhere'.

• Layer 3. Section Schemas - this is feature/row level config first introduces in the home page to segment ket page elements and adds a add/remove/edit lifecycle to them

• Layer 4+ Block schemas - now we're down to the insides of sections and it's pretty unstructured as to what goes on here.

From a developer point of view, layouts, templates, sections, and blocks are all basically the same thing -- a scoped element with slot(s) to insert child content, aka components?

[PaulNewton]

From a developer point of view, layouts, templates, sections, and blocks are all basically the same thing
Sure for the narrow view of where-do-I-expose-these-settings or if your using asset-api to push a file, otherwise there's no where enough feature parity among those template types to treat them as the same concepts in practice; and that's before scope rears it's head 🔥 🐲 .

• layouts , also as UI chrome, shopify code injection requirements, supporting third-party support that needs things added to "theme.liquid"*, and in an ideal world dev-environ global flags.
• templates, also as merchant organization of features for theme & object(products,pages,etc)
• sections , also as section-rendering api targets, local config or ?overrides?, themes features list.

*At least till we get custom-liquid that works like custom-css settings.

[stephanie-shopify]

Interesting that you used the word philosophical because we did too.

Our theme dev asked ourselves the question 'what is the difference between a section and block anymore? do we really need sections anymore? what if we pushed ourselves to build a full page as a single section, containing all the blocks?" We actually did run through that thought exercise with the homepage.

Our conclusion was, it's totally possible for a page to be just one section containing a lot of blocks. Sections are now organizational concepts and they are strictly full page width. Blocks can be any width.

That is currently the main difference.

I realize this doesn't answer your questions on the role of sections. We do think it would be very difficult to actually deprecate sections so it's not really something we are considering right now. However, practically speaking- we do see a future where pretty much everything in a theme is a block.

[PaulNewton]

@panoply I've wanted something like this native for a long time so now might be the right time to try and get it,
#42 Use {% render %}, vars, assets , or other inside {% schema %} to make repeated settings modular, reduce duplicated settings code

[jdunham2]

We also found reusable schema to be super valuable but implemented it by extending the functionality of {% schema %} such that it works like {% render %} when a filename or variables are passed to it.

E.g. {% schema 'filename', var: value, var2: value %}

We also use a schema folder for the shared content. The schema files themselves can reference other schema files as well. And we added support for If, Elsif, Unless conditionals so we can do things like default to desktop values when mobile fields are left blank.

We also loving the theme blocks and the new size layout and spacing panels so went ahead and integrated them using CSS variables in our reusable schema implementation, modeling it after how the reference theme was done.

[panoply]

IMO That is a huge anti-pattern. The infused syntactical structure imposed to achieve the schema structure goes against best practices and effectively kills any IDE features.

[jdunham2]

True, implementing any feature like this, regardless of the name, would require an update to the IDE extensions to support the syntax.
The name of the tag is just what we chose to use and could easily be changed. But the structure here would be the same as proposed in #45 just with a different tag than render since that always points to the snippets folder currently.

[PaulNewton]

Is that schema nesting done with a modified syncify, a different build script, or this just capture parse parameter passing pattern.
👨‍💻 reader also see [inline_asset_content](https://shopify.dev/docs/api/liquid/filters/inline_asset_content) as an inclusion method.

Good sample of why a native behavior for DRY schemas is needed though I guess.
On the other hand man is theme complexity getting to be too much I would never want to see that type of nesting in a store theme or pass off to a merchant that doesn't have a dedicated dev/theme team.

Until some in platform solution does exist these type of workarounds are still a complexity indicator for using headless instead.
Meaning for complex storefronts a theme has likely already outgrown the online-sales channels theme-liquid and should be probably moving towards headless to have a build process*. Or there may be a serious mismatch in expectation & utilization of an introductory platform tool vs dev/maintenance costs of cramming more into less.
Not a fun middle-ground for theme developers on the outside to be stuck in 🗿👨‍💻🗻 but possibly profitable for those with proprietary solutions or the right clients.

*N.B. online sales channel should never have a "build" process, up to not even opening the door a little with features like UID generation. Shopifys theme ecosystem in tooling ,merchant/dev support etc has always been waaaay to sloppy for that.

[PaulNewton]

The important one:

What level of granularity should theme blocks aim for to optimize the merchant experience?

Any subfeature\component of a UI pattern a merchant wants needs to frequently customize the behaviors and aesthetics of; while maintaining a high level of consistency in the face of merchants trying to wear the designer hat to minimize them from having to hand edit files.
That also cannot be solved in under ~15minutes by custom-liquid settings/sections/blocks i.e. stuff that has specific CSS layout or wrapper styling or dynamic behaviors i.e. variant data that would force a merchant to wade through the files code or browser-devtools to find the relevant names of things.

Badges* are probably the most useful UI smallest example to think about what the axioms will be and where the lines are between theme-settings vs section-settings vs theme-blocks(component-settings|slot-settings) before crossing over into atom/token/utility territory.
They cover a lot ground for a lot people as the smallest "thing" in theme support; as merchants ,designers , and developers quickly get the concept but everyone has VERY different ideas of how badges should operate when setting up a theme. Some themes have product-tag conventions, others translations, others strings in theme settings, etc but at the end of the day merchants just need business logic.
*(sale badges, out of stock label, % off discount tags, etc )

🤔 Does the nestable-block paradigm mean .product-cards are gonna be expected to have their own headers footers blocks which in turn have badge blocks?

Or just about every component gets it's own header/footer combo for allowing placement of meta info(badges,skus,vendor names,etc)

For a frequency of usage guideline the largest example is homepage hero images/banners in which as many UI subcomponents as possible should probably be blocks; . As it's reasonable to expect a merchant changing the campaign for the hero-image every month. 🤔 find the most complicated landing hero you can and make it blocks and in that find a truth

Beyond that it's gonna be all reasonable** upfront expectations of common frustrations for both merchants and devs , then usage reports, then feature requests. **unfortunately there's not global repo of common pattern issues in shopify themes to know what's publicly reasonable it's a miasma free for all.

I feel a bit nauseous when I think about what messes I'm gonna have to wade through to fix things when slideshows start using nested blocks 😷 .

---

what intrinsic value do sections hold, if any?

As concept/labels for UI patterns and containers for configuration of itself and children.

render traditional sections (and even snippets at some degree) obsolete

shuffling everything into blocks will be an anti-pattern. snippets are here to stay as liquid isn't flexible enough to let us create objects in it, unless shopify implements some sort of build tooling in the admin itself to help keep things DRY. managing the duplicated {% schema %} in blocks is gonna be obnoxious 🤢

Is there a need to distinguish between "layout" and "functionality" blocks in the future?

There's a need now for better verbiage and UI, see "separator" blocks/settings which work okayish but kinda become non-intuitive when it is a HORIZONTAL separator being organized in the sections sidebar VERTICALLY , such as for a header and you need to dictate what goes left and right. Nestable-blocks solve this at least organizationally somewhat but still it's vertical settings for a horizontal visual output.