Blocks: Deprecate registerBlockTypeFromMetadata in favor of registerBlockType
#32030
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gziolo
added
the
[Feature] Block API
gziolo
force-pushed
the
update/deprecate-register-block-type-from-metadata
branch
from
49d7420
to
9334ff2
Compare
youknowriad
approved these changes
May 20, 2021
youknowriad
reviewed
May 20, 2021
| } | ||
|
|
||
| if ( isObject( blockNameOrMetadata ) ) { | ||
| unstable__bootstrapServerSideBlockDefinitions( { |
There was a problem hiding this comment.
This just fills serverSideBlockDefinitions that is used a few lines under right? In theory we could avoid it here right?
There was a problem hiding this comment.
In the future, we could. At the moment it contains some backward compatibility logic for apiVersion.
There was a problem hiding this comment.
gutenberg/packages/blocks/src/api/registration.js
Lines 174 to 185 in 298f508
|
Size Change: +83 B (0%) Total Size: 1.62 MB
ℹ️ View Unchanged
|
gziolo
added
the
[Type] New API
gziolo
added
the
Needs Dev Note
15 tasks
youknowriad
removed
the
Needs Dev Note
ofhouse
added a commit
to ofhouse/DefinitelyTyped
that referenced
this pull request
Aug 19, 2021
registerBlockType now accepts input from the block.json metadata WordPress/gutenberg#32030
8 tasks
typescript-bot
pushed a commit
to DefinitelyTyped/DefinitelyTyped
that referenced
this pull request
Sep 23, 2021
…ofhouse * @wordpress/blocks: Register block from metadata registerBlockType now accepts input from the block.json metadata WordPress/gutenberg#32030 * Derive example attributes from block #55245 (comment) * Stronger typing for example/innerBlocks #55245 (comment) * Provides stronger typings for providesContext #55245 (comment) * Rename generic type from T -> TAttributes #55245 (comment) * Derive innerBlocks from Block properties #55245 (comment) * Reuse block props in example * Make innerBlocks in example optional
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Props to @mtias for the proposal. Rather than using two distinct methods to register block types in the block editor, let's make
registerBlockTypethe canonical method to deal with all use cases. In practice, the PR proposed extends its usage to work as a proxy the formerregisterBlockTypeFromMetadata. 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
registerBlockTypemethod from@wordpress/blockspackage to register a block type using the metadata loaded fromblock.jsonfile. All localized properties get automatically wrapped in_x(from@wordpress/i18npackage) function calls similar to how it works in PHP withregister_block_type. The only requirement is to set thetextdomainproperty in theblock.jsonfile.Example:
block.json{ "name": "my-plugin/translatable-block", "title": "My translatable block", "description": "My block with translatable metadata", "keywords": [ "translatable" ], "textdomain": "my-plugin" }index.jsHow has this been tested?
Unit tests were updated.
I also tested deprecations for
wp.blocks.registerBlockTypeFromMetadatain the Browser Console:Screenshots
Types of changes
API change and deprecation.
Checklist:
*.native.jsfiles for terms that need renaming or removal).