Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

shimAttributeSource: don't run outside the registerBlockType filter #53015

Merged
merged 1 commit into from
Jul 28, 2023
Merged

shimAttributeSource: don't run outside the registerBlockType filter #53015

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 1 addition & 25 deletions packages/editor/src/hooks/custom-sources-backwards-compatibility.js
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,8 +1,7 @@
/**
* WordPress dependencies
*/
import { store as blocksStore } from '@wordpress/blocks';
import { select as globalSelect, useSelect } from '@wordpress/data';
import { useSelect } from '@wordpress/data';
import { useEntityProp } from '@wordpress/core-data';
import { useMemo } from '@wordpress/element';
import { createHigherOrderComponent } from '@wordpress/compose';
Expand Down Expand Up @@ -124,26 +123,3 @@ addFilter(
'core/editor/custom-sources-backwards-compatibility/shim-attribute-source',
shimAttributeSource
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to confirm, there's no way registerBlockType() will be called before this filter has been added?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

registerBlockType still can and will be called before adding this filter. But now there is a point, very late in the editor initialization, where the filters are re-applied. Basically re-registering the blocks once again. That's the __experimentalReapplyBlockTypeFilters action. If some block got initially registered before all filters were added, the registration will be performed once again, with the new set of filters.

The core/blocks store has two state slices for this: state.unprocessedBlockTypes contains the raw block data with the filters unapplied, and state.blockTypes contains the filtered block types. You can regenerated the blockTypes from unprocessedBlockTypes at any time, multiple times.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, thanks for confirming 👍

);

// The above filter will only capture blocks registered after the filter was
// added. There may already be blocks registered by this point, and those must
// be updated to apply the shim.
//
// The following implementation achieves this, albeit with a couple caveats:
// - Only blocks registered on the global store will be modified.
// - The block settings are directly mutated, since there is currently no
// mechanism to update an existing block registration. This is the reason for
// `getBlockType` separate from `getBlockTypes`, since the latter returns a
// _copy_ of the block registration (i.e. the mutation would not affect the
// actual registered block settings).
//
// `getBlockTypes` or `getBlockType` implementation could change in the future
// in regards to creating settings clones, but the corresponding end-to-end
// tests for meta blocks should cover against any potential regressions.
//
// In the future, we could support updating block settings, at which point this
// implementation could use that mechanism instead.
globalSelect( blocksStore )
.getBlockTypes()
.map( ( { name } ) => globalSelect( blocksStore ).getBlockType( name ) )
.forEach( shimAttributeSource );
Loading