Looking for usecases

[miazbikowski]

Hello partners,

We’ve outlined certain cases for restrictions we believe would make sense to have:

(Note: for brevity, a container is a section or a block which can contain other blocks)

• A block that only goes into one or more containers, but not all containers (a “private” block)
• A block that can go anywhere (a “public” block)
• A container that accepts all public blocks (and any number of private block)
• A container that accepts some public block, but not all (and any number of private blocks)

We are also trying to identify cases in which “allowances” (when you’re allowing a block) should be inherited by blocks at all levels of nesting, versus cases where these should only affect the container’s immediate children. 

For example:
“I’m a Featured Product section and I’ve allowed certain private blocks. I want these to be useable even in my nested blocks.”

VS

“I’m a slideshow, I allow only slide blocks. I don’t want to allow any of my nested blocks to allow slides.” (This allowance shouldn’t trickle down)

We want to make sure we cover any and all use cases which you believe you might come across.

We would appreciate your input with cases of your own such that we will not limit ourselves with cases present only in our in-house built themes.

Your participation is much appreciated. Thank you!

[dhruveonmars]

@miazbikowski I'm going through and trying to list a load of use-cases, but wondering, in these examples of private vs public blocks. Are they all theme blocks? If so, can private blocks get passed any attributes from the container like standard 2.0 blocks can still access the section object or are theme blocks always restricted to theme settings and block settings only.

Is there a concept of a required block, or can there be?
Eg, in a featured collection/featured products section, it would be great if a product card block/container is always required.

[PaulNewton]

Yes for required blocks or some sort of affodance.
This smacks right into an intersection of theme-blocks not accessing sections and vice-versa 🤔 so we can't conditionally make a section not render anything; and we cannot add custom warnings to the settings sidebar (no conditional behavior), and on top of that the guidelines cautions us on showing anything in the preview that wouldn't render on the customer storefront.

[miazbikowski]

Hi @dhruveonmars - thank you for your questions!

This concept of a public/private theme block would be only for theme blocks, yes. It would be a way to ensure some more restrictive containers only allow adding certain blocks. For example, a slideshow might only want to permit slides to be added. This is because we can reasonably assume, given our own in-house theme prototyping, that the javascript would break if any other block were added to the slideshow.

This concept of private/public blocks has no impact on the scoping of theme blocks (what they have access to). [Or rather, that would hopefully be a separate conversation, unless you believe there is a valid reason why these two concepts cannot be extricated]

As for required blocks, that is something my colleagues are looking into, separate from the concept of public/private blocks since it serves different usecases.

I hope that helps!

[dhruveonmars]

Thanks @miazbikowski.

I've been trying to figure out how best to articulate what we envision for usage and flexibility.

Adding this screenshot showing some example usage of sections and blocks.

It does become a bit tricky, eg the "Main" block, may have slightly different settings available depending on the parent section it belongs in. Eg, if a featured collection, it could have carousel options. If a media section, it could have additional layout options with other media blocks available. So in these cases, would it be a private block still, unique to each section?

So, public blocks - would be available everywhere public blocks were allowed, eg text block, image block, etc.
Some blocks, would be private, and only accessible by a particular parent container, eg product title would only be available within a product card block. this would be available in specific containers, but vary per section. eg - in a 'Featured Collection' section - we would select a collection at the section level, and that would automatically define the content of the loop of product cards around the 'main' container. They wouldn't need to select collection or cards multiple times.
Similarly, 'Featured Products' section would select products at the section level and that would feed down.

In the opposite way, we would want to know what blocks/settings are configured so the parent can adjust accordingly. Eg, in a section, if we add a 'sidebar' block, the section should automatically split accordingly (eg 25% 75%). This may only be possible with flex, but what if grids were being used? Similarly in product card blocks, we'd need to know if the blocks placement for content was below the product card image, or above it, so the parent would need to have knowledge of the child blocks settings, and vice-versa.
I think for public blocks, yes those could be separate from this conversation, unless it becomes a generic method available to all blocks - reading parent/child settings.

Apologies in advance if this goes off topic. Just trying to paint a picture of everything holistically, as it's a bit difficult to split up. Hopefully this helps, but if there's other threads where some of this may be more appropriate, happy to post in there, or if there's anything unclear or confusion, happy to try and elaborate further.

[PaulNewton]

A native built in custom-liquid section that has access to all 'public' blocks.
No theme developer creation required to make this section, all themes get it ala custom-css setting.

[PaulNewton]

Spitball on the syntax of the allow/disallow lists,
The pies already been baked on this probably using name properties,
but being able to use CSS selectors, to define the ruleset of allowed/disallowed combinations could be a bit of sanity for an otherwise open-ended nesting free for all. Or emmet 🤔 ? syntax to get around CSS defects.

{ 'allow': '.slide > .image , .image > .text + .button , .slide >.button + .text' },
{ 'disallow': '.button > .image , .text > .image' }
The meta problems with this of course is using CSS class names of the blocks class property vs the blocks name property. And the combinatorics that some devs might create very large selector lists since CSS doesn't have logic like AND OR etc operators or backtracking. That is doesn't handle rendered conditions such as add a css class that is the current product.templates suffix so a block doesn't appear on certain products i.e. products NOT tagged sale don't get access to a sale badge block.
And people at first confusing the limitations of CSS as a theme architecture issue.

[PaulNewton]

Examples

• Adding a message/banner on the PDP's main product-info shouldn't in turn be usable in all other product displays such as product cards for recommended products or in quickviews.
• Headers should not allow merchants to put any social share icons in the very top left as it encourages bounces.
• If I add a custom-liquid customization to a theme I have no real built in way to enforce what snippets a merchant might render, only the arbitrary feedback for liquid-errors, or {% capture %} parsing shenanigans.
• product form inputs should only appear if there's a product form
• hero banners etc media-blocks disallow autoplay video blocks, it should extra conscious steps to add such behaviors to a page as a stand alone block that has it's own informational text/links/tutorial-video to educate a merchant on best practices to avoid merchant inflicted footguns

[PaulNewton]

DX of editing allow/disallow entries,
If I customize a theme I might make an offshoot of files to to minimize edits and speed up future upgrades to original files.
Say for a b2b collection some products require minimum orders and cannot show pricing
I'd have the original price.liquid then create a price-moq.liquid

In how many places could I end up having to editing to switch out this file reference.
Are so many files edited, even if just schemas, it defeats the initial purpose of trying keep original files untouched.