Description

Props to @mtias for the proposal. Rather than using two distinct methods to register block types in the block editor, let's make registerBlockType the canonical method to deal with all use cases. In practice, the PR proposed extends its usage to work as a proxy the former registerBlockTypeFromMetadata. It should remove some confusion that we observed and let us be more explicit what's the latest recommendation. It will also allow us to better communicate what's the preferred way to register block types in the context of WordPress.

We have already applied a similar change in WordPress core:
WordPress/wordpress-develop@6ad4e34

Dev Note

This is the updated note from #30293:

In JavaScript, you can use now registerBlockType method from @wordpress/blocks package to register a block type using the metadata loaded from block.json file. All localized properties get automatically wrapped in _x (from @wordpress/i18n package) function calls similar to how it works in PHP with register_block_type. The only requirement is to set the textdomain property in the block.json file.

Example:

block.json

{
	"name": "my-plugin/translatable-block",
	"title": "My translatable block",
	"description": "My block with translatable metadata",
	"keywords": [ "translatable" ],
	"textdomain": "my-plugin"
}

index.js

import { registerBlockType } from '@wordpress/blocks';
import Edit from './edit';
import metadata from './block.json';

registerBlockType( metadata, {
	edit: Edit,
	// ...other client-side settings
} );

How has this been tested?

Unit tests were updated.

I also tested deprecations for wp.blocks.registerBlockTypeFromMetadata in the Browser Console:

wp.blocks.registerBlockTypeFromMetadata( { name: 'test/block', title: 'Test block' } );

Screenshots

Types of changes

API change and deprecation.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• I've tested my changes with keyboard and screen readers.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).