How should we handle different layers/states for the same block in the editor?

[SantosGuillamot]

Description

Part of #41236.

This topic has been already discussed in some issues/PRs, so I'm just gathering them here to have a single place to talk about it.

In order to keep improving the great UX Gutenberg provides, it could be interesting to discuss the best way to handle different layers and different states for the same block (some examples below), and maybe define a standard for this. Currently, it isn’t clear to me the best way to handle this, and I can imagine more blocks needing this once users create more complex interfaces.

The way I see it, handling layers and states could be different use cases but, as the potential solution may be similar, it could make sense to discuss them together.

@ajlende already shared some use cases in this comment, so I’m mostly copying it here:

Different states

In some blocks, the content and styles will be different depending on the state of the user or the site. Some examples that have come up so far:

• Query block - Add a configurable “no posts found” state: If there are no results in the search terms, users may want to show a different message. Ideally, this should be handled directly through blocks.
• WooCommerce cart block - Separate rendering for empty vs full carts (CFT post): Similar to the previous case, if the cart is empty or not, the layout will be different.
• Comments Form block: Depending on if the user is logged in or not, the messages of the form will be different. For example, if the user is required to be logged in to comment, it could show a message instead of the form.

Different layers/modes

• Cover block - Background Editor for Cover block: "Right now it's difficult to achieve effects such as text overflowing images... One way in which we can allow this to be done with ease is by having background editing options directly in the Cover block itself."
• Image block - Improve UX of image crop/edit tools: “The current flow of image edit tools within the Image block are great, though the experience using the controls could be improved to better indicate the available tools, as well as clean up the interactions.”

Explored solutions

@critterverse and @javierarce shared a great design proposal that would enable background editing functionality for the Cover block. I feel it could be used to define a toolbar control that easily lets you change between layers/states and clearly shows which part the user is editing. For full context, please take a look at the comment, but this is how it could look like:

Similar to this, this is how the WooCommerce Gutenberg Blocks plugin dealt with this in the cart block depending if the cart is empty or not.

Filled Cart

Empty Cart

Once we reach an agreement on how this could work in terms of UX, we can start talking about how it would work in terms of code.

Questions

Some questions that come to my mind:

• Does it make sense to define a standard to handle this and provide the block developers any tools to use it in their blocks? Or each block developer should handle it however they prefer?
• Is the toolbar controls the proper place to switch between these layers/states?
• Would it make sense to provide any default Block Toolbar controls for this?
• How could this be done both in terms of design and code development?
• Are there other similar use cases not mentioned here?

Anything else? 🙂

[jasmussen]

One exploration that is inspired by @critterverse and @javierarce above, is mocked up for image tools in #38988. The bigger change here is the reduction of the secondary toolbar to being hidden behind a "back" button, rather than a bigger label. Mostly, it might be a simpler place to start, and we can see how well that works; but there's also a concern of the block toolbar growing too wide otherwise, especially with translations.

[aurooba]

I'm wondering how the back button setup can be used here, how would you know which state you're editing without a label? You shouldn't have to look in the List View or the Breadcrumbs to know which state you're editing, right?

[jasmussen]

Block toolbars should remain as simple as we can possibly make them, and blocks should probably not have multiple secondary toolbars. The secondary toolbar would also be dismissed as soon as you deselect a block, meaning, you'd only ever get to the secondary toolbar by first selecting a block, then selecting a button for the toolbar, both providing context for the secondary layer.

[michalczaplinski]

Thanks for starting this convo, @SantosGuillamot! I think this is an important aspect of work on interactive blocks that was bound to come into play sooner or later.

I don't have the answers to the more design-related questions, but about this one:

Does it make sense to define a standard to handle this and provide the block developers any tools to use it in their blocks? Or each block developer should handle it however they prefer?

It definitely does. Blocks that are interactive, by definition, must be able to store some piece of internal state and render different UIs depending on that state. So, I think that it's important that we provide the developers with the right APIs that can be used to register "modes" that depend on some internal state of the block and have the UI to display them.

This nomenclature should also be well-defined, of course - I called them "modes" but maybe they should be "states" or "layers" like in the title of the OP.