Blocks: Add support for block name aliases for variations

[gziolo]

What problem does this address?

Part of Block API roadmap #41236.

Let's explore whether some block variations can be read as a block type. For example, instead of core/template-part/header be able to just have core/header to still get resolved by the template part functions. We used to have a similar granular naming schema for Embed and Social Link blocks before we converted them to block variations:

gutenberg/packages/blocks/src/api/parser/convert-legacy-block.js

Lines 23 to 29 in bdb6a41

	// Convert derivative blocks such as 'core/social-link-wordpress' to the
	// canonical form 'core/social-link'.
	if ( name && name.indexOf( 'core/social-link-' ) === 0 ) {
	// Capture `social-link-wordpress` into `{"service":"wordpress"}`
	newAttributes.service = name.substring( 17 );
	name = 'core/social-link';
	}

gutenberg/packages/blocks/src/api/parser/convert-legacy-block.js

Lines 31 to 50 in bdb6a41

	// Convert derivative blocks such as 'core-embed/instagram' to the
	// canonical form 'core/embed'.
	if ( name && name.indexOf( 'core-embed/' ) === 0 ) {
	// Capture `core-embed/instagram` into `{"providerNameSlug":"instagram"}`
	const providerSlug = name.substring( 11 );
	const deprecated = {
	speaker: 'speaker-deck',
	polldaddy: 'crowdsignal',
	};
	newAttributes.providerNameSlug =
	providerSlug in deprecated
	? deprecated[ providerSlug ]
	: providerSlug;
	// This is needed as the `responsive` attribute was passed
	// in a different way before the refactoring to block variations.
	if ( ! [ 'amazon-kindle', 'wordpress' ].includes( providerSlug ) ) {
	newAttributes.responsive = true;
	}
	name = 'core/embed';
	}

Benefits of using aliases

• Aliased block names would get converted into unique class names assigned to block variations, giving more options to style their sites.
• Manipulate in theme.json granularly (like attach custom CSS that only is used when the block is used, etc.).
• Aliases used would give easier access for site owners to the content analysis of which blocks and variations are used in posts and templates.
• Benefit from all the block API tools in existence (like multiple block support).

What is your proposed solution?

Add handling for block type name aliases used with block variations. They should fall back if necessary to the original block type name, e.g. woocommerce/product-list that can get resolved to the product-list variation added to the core/query block.

Some examples to consider:

<!-- wp:template-part {"slug":"header","theme":"twentytwenty"} /-->
<!-- wp:meta { "name": "mykey", "type": "heading" } /-->

becomes

<!-- wp:template-part/header {"theme":"twentytwenty"} /-->
<!-- wp:meta/mykey { "type": "heading" } /-->

This could also remove the need for complex logic used with block variations when detecting the variation based on the result of the isActive callback executed.

[louwie17]

Hey @gziolo has there been any more progress around this idea/issue?
I think this would be a great feature to have and may really benefit us in WooCommerce when laying out the template for the new product editor.
We currently make active use of attributes and re-use blocks quite often, I think something like this would offer two big benefits for us:

• Clean up the actual template by being able to remove a lot of our attribute values
• Make better use of block hooks, as this will allow 3rd party plugins to hook into variations*

*This will depend if the above proposed solution will also work with block hooks.

A current example would be:
We have a section block, which renders a unique title/description and renders nested blocks. We have several sections across the product editor page. Like a general details section, a pricing section, an attributes section.
It would currently not be possible to extend after a specific section ( like pricing ) by a 3rd party plugin, but with the above they could, as they could hook into the wc:section/pricing for example.

[gaambo]

I guess this would also allow setting allowedBlocks/template on innerBlocks to allow only some variations inside it? For Example we're using a variation of core-media/text to show a team member with some data - the innerblocks of the core-media/text block are locked. We then have a group block as section in which editors can insert these blocks. At the moment we've locked the group block to allow only core/media-text blocks, but of course the editors could also insert a non-team-member variation of the media-text blocks.
So this would be great for such use cases as well - if I understand it correctly?

[gziolo]

So this would be great for such use cases as well - if I understand it correctly?

Potentially. It didn't occur to me initially, but now that you said it, it's worth considering as that would be a very interesting use case. It would also play nicely with block variations that define block bindings, so potential Site Title and Post Title could be replicated with the Heading block but maybe people still would want to have a control where to insert it.

[tjcafferkey]

I'm still in the process of understanding the complexities in this since this code is unchartered territory for me, but having given this a little bit of thought and there are a few things I think we need to consider, unless I have over complicated it:

• Currently each variation can be registered using the registerBlockVariation function which only registers it client side for the purpose of the new variation being discoverable in the inserter (ie they're not registered as a new block type). If we want to create an alias registered on the server too we'd need to provide a PHP counterpart method or other means (block.json?) of allowing users to register their variation/alias block.
• We need to update the block validation process to ensure when this alias'd block is inserted or read, it isn't reported as corrupt/errored.
• Unless I'm misunderstanding how things currently work but I don't think the server understands the concept of variations the same way the client does. In the eyes of the server an original block and a variation block are one block with the same markup but different attributes/inner blocks. We'd need to think of a way to introduce this concept, I think?