Do not render anything if blocks output nothing

[bakura10]

Hi :),

As of today, if a block does not output anything, it will still output in the DOM the wrapper:

{{ block.settings.text }}

{
  "name": "Text",
  "settings": [
    {
      "type": "text",
      "id": "text",
      "default": "Welcome to our store",
      "label": "Content"
    }
  ]
}

Especially with settings bounded to metafields that might be empty, this will generate a lot of empty DOM elements:

We often use the sibling selector in CSS, and this basically breaks it.

[ludoboludo]

Hey @bakura10, you can actually opt out of having a wrapping element by adding "tag": null

{
  "name": "Text",
  "tag": null,
  "settings": [

Here is more info about it

Unless I'm misunderstanding and you had done that already 🤔

[bakura10]

Ah yeah I miss this. But this should then be the default as I will basically need to do that for all blocks. I think Shopify could abstract it and keep the wrapper (the wrapper has the benefit that you don’t have to output block.shopify_attributes yourself) but do not output the wrapper if nothing is rendered in the block

[ludoboludo]

Isn't it odd for the block to output nothing ? Having it showing in the sidebar but doing nothing on the actual theme 🤔

I guess a merchant can do this by having a text block and removing any text from the block setting. So it would be a good fallback and that's usually where we've used conditionals (if block.settings.text == blank...).
But if a wrapper is always outputted then there is no way to conditionally hide it.

So that's where you'd enjoy it if the platform was a bit smarter and didn't always add an wrapping element eh? 🤔

Though I still see a benefit to having "tag": null as an option.

[bakura10]

The most common use case of content being empty: a merchant create a block and connect the content with a meta field. This metafield might not have value for a lot of different products.

[tyleralsbury]

This use case makes a lot of sense and is quite interesting. It can happen for pretty much any block and may lead to a lot of empty space if there isn't a way to account for it (padding / margins / etc...) Thanks @bakura10 !

[t-kelly]

Another perspective here -- what I feel like this overlaps with is how sections/blocks/themes handle placeholder content, ie. what gets rendered when the intended content is not set.

Maybe a pattern that could be defined here to handle this case + all other placeholder content cases?

[ludoboludo]

+1 on this. If you're wanting to show a different placeholder image based on the context you can't. Same for info or paragraph from the sidebar settings.

[PaulNewton]

based on the context you can't

maybe for surrounding sections/blocks settings we can't access the scopes, i.e. which block is the next sibling , though for sure things like product.template or product.tags are used to swap placeholders. Though we're cautioned to not show stuff in preview not shown on the customer-storefront.

But at the same time since we can't change the sidebar conditionally either ALL information has to try and be baked into the settings info/paragraph or links; or the preview caution has to be ignored to insert warnings or onboarding content in place of meaningless placeholders.