Inserter Tweaks for Child Blocks

[mtias]

With Child Blocks API merged into master, there are a few extra improvements we can make. Currently, the relationship between a child block and its parent is not immediately evident in the inserter — the only visual change is that child blocks appear only when in context of the parent, and that they show first in the list.

One thing I'd like to explore is signaling which blocks have children assigned in the main inserter and then, once within the context of the parent, clearly list the available child blocks as a group.

@jasmussen did some design explorations on how this could work.

1) Blocks with children would show a subtle hint as a stack of cards:

This would also work in tandem with the idea of letting block authors color-code their blocks.

2) Once a user is within the context of such a block, the available child blocks are listed at the top, and the parent block is provided as anchor:

[jasmussen]

The pattern used here is inspired by the mockup work we did for inline blocks in #5794 (comment), but takes it slightly further. Here's how the pattern above could look when applied to those:

Worth noting that inline blocks are not the same as child blocks, so you'd never see for example the Paragraph block as a "stacked blocks" just because it can have inline blocks inside. But there's no reason we can't use the same pattern.

[youknowriad]

How this would relate to allowing custom block categories? There's some overlap.

[mtias]

I don't think there's much overlap with categories. The main thing here is that Woo Product is a real block, not just a group of blocks — clicking on it will insert something, not just expand the contents.

[aduth]

This would also work in tandem with the idea of letting block authors color-code their blocks.

Could this just be a property of the Plugin API to associate a brand color to the plugin (and use in UI as applicable)?

[mtias]

What if you have blocks but are otherwise not using the Plugin API at all?

[karmatosed]

Just wanted to add that I really like these as a solution, it seems clear and logical.

[aduth]

What if you have blocks but are otherwise not using the Plugin API at all?

At the risk of opening a rabbit hole, maybe we need a more formalized relationship between a block type and a registered plugin, instead of the namespace convention? Currently there's no way to associate a plugin which also registers blocks, except by its plugin name vs. block namespace, which aren't guaranteed to be equal. By formalized relationship, I could imagine either blocks as a property of a plugin registration object, or the return value of the registration being an object which contains various APIs:

wp.plugins.registerPlugin( 'my-plugin', {
	// ...
	blockTypes: {
		'map': {
			// ...
		},
	},
} );

var plugin = wp.plugins.registerPlugin( 'my-plugin', {
	// ...
} );

plugin.registerBlockType( 'map', {
	// ...
} );

[mtias]

Mmm, not sure that would be ideal. In my mind, most plugins would either register a block, or use the Plugin API to provide functionality in another way. We could think about extending that, but the ability for a block to specify a color should also be allowed in any case. Sounds easier to start there and see if we need a more formal relationship.

[jorgefilipecosta]

#7003 was merged so I think we can close this issue. If there are further improvements required feel free to reopen.

[mtias]

We just need to add the API for supplying a bg color to the block icon card.

[jorgefilipecosta]

We just need to add the API for supplying a bg color to the block icon card.

Sorry, @mtias missed this one. Right now we set a class for each inserter item editor-block-list-item-[block-name] e.g:editor-block-list-item-acme-product or editor-block-list-item-gallery.
Maybe we can document a sample where these classes are used to change the design of an inserter button e.g: the color of the inserter. Do you think doing that would be a good solution?

[mtias]

Probably not, that seems a bit fragile — and won't scale to contexts like mobile apps. People would have to potentially overwrite multiple selectors for all the appearances of a block, and we won't be able to ensure consistency for users.

[jorgefilipecosta]

Ok, I'm reopening this issue as we will need to provide a special API.
My initial idea of a possible API is to use an inserterBgColor property in the block registration but I'm still thinking about what are the other possibilities we have.

[mtias]

I think we could do something like:

icon: [
    svg || dashicon-string,
    '#color-value',
]

If the property is not an array, we assume svg/dashicon-string.

[mtias]

inserterBgColor is too specific for the inserter.

[jorgefilipecosta]

Nice idea @mtias I will submit a PR with the implementation of it, so we can see how it looks.

[chrisvanpatten]

Would you also need to provide an icon color (for dashicons) to make sure there's sufficient contrast on the icon? Or is that something Gutenberg itself can handle?

[jorgefilipecosta]

@chrisvanpatten excellent question, Gutenberg itself can use https://github.com/bgrins/TinyColor mostReadable function to compute the best color for given background color according to the set we provided. But I'm not sure if we should do that or allow the user to configure both colors.

[chrisvanpatten]

@jorgefilipecosta i think it makes sense to allow the foreground color to be set specifically… it removes ambiguity and means any app consuming Gutenberg blocks doesn't need to implement their own platform-specific color contrast checker.