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:
|
// 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'; |
|
} |
|
// 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.
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/headerbe able to just havecore/headerto 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
gutenberg/packages/blocks/src/api/parser/convert-legacy-block.js
Lines 31 to 50 in bdb6a41
Benefits of using aliases
theme.jsongranularly (like attach custom CSS that only is used when the block is used, etc.).multipleblock 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-listthat can get resolved to theproduct-listvariation added to thecore/queryblock.Some examples to consider:
becomes
This could also remove the need for complex logic used with block variations when detecting the variation based on the result of the
isActivecallback executed.