Blocks: Apply the most recent filters to previously registered blocks #34299
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
[Feature] Block API
|
Size Change: +317 B (0%) Total Size: 1.07 MB
ℹ️ View Unchanged
|
gziolo
force-pushed
the
update/split-block-registration-two-phases
branch
2 times, most recently
from
dc1445a to
ec3f8cc
Compare
gziolo
added
the
[Feature] Extensibility
gziolo
force-pushed
the
update/split-block-registration-two-phases
branch
2 times, most recently
from
eeaece0 to
096c7ea
Compare
gziolo
added
[Status] In Progress
|
Performance impact for 100 custom block types and 100 filters updating block types meassured with the following code: diff --git a/packages/blocks/src/store/controls.js b/packages/blocks/src/store/controls.js
index 9030abf01c..afc3baa19d 100644
--- a/packages/blocks/src/store/controls.js
+++ b/packages/blocks/src/store/controls.js
@@ -130,6 +130,7 @@ const controls = {
),
REAPPLY_BLOCK_TYPE_FILTERS: createRegistryControl(
( { dispatch, select } ) => () => {
+ const startTime = performance.now();
const unprocessedBlockTypes = select(
STORE_NAME
).__experimentalGetUnprocessedBlockTypes();
@@ -152,6 +153,11 @@ const controls = {
}
dispatch( STORE_NAME ).addBlockTypes( processedBlockTypes );
+
+ console.log(
+ 'Execution time (ms):',
+ performance.now() - startTime
+ );
}
),
};Results:
Average time: 39 ms. |
gziolo
commented
Aug 26, 2021
gziolo
force-pushed
the
update/split-block-registration-two-phases
branch
from
addebe8 to
393278e
Compare
gziolo
requested review from
adamziel,
draganescu,
getdave,
kevin940726,
noisysocks,
talldan and
tellthemachines
as code owners
|
The usual dance to register blocks becomes quite messy and it is duplicated with customizations in 5 places for the web. We will have to improve it in a follow-up PR. Maybe, we could tackle it together with the migration to using the REST API endpoint for block types as explained in #22812. dispatch( blocksStore ).__experimentalReapplyBlockTypeFilters();
registerCoreBlocks();
if ( process.env.GUTENBERG_PHASE === 2 ) {
__experimentalRegisterExperimentalCoreBlocks();
} |
gziolo
force-pushed
the
update/split-block-registration-two-phases
branch
from
c954944 to
7f10bf3
Compare
gziolo
force-pushed
the
update/split-block-registration-two-phases
branch
from
7f10bf3 to
aaabad7
Compare
youknowriad
approved these changes
Oct 14, 2021
Fair enough. I'm worried as well. Let's see if it doesn't produce new issues when resolving some of those that existed for so long. |
2 tasks
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
Fixes #9757.
Fixes #14578.
The problem
Same 3rd party blocks get registered with
registerBlockTypebefore other plugins register their filters that modify blocks during block registration.Implementation details
The proposed solution re-applies filters to the registered blocks just before the block editor starts the parsing step. At the moment it's applied only the edit post screen in the
initializefunction just before all core blocks get registered.The idea looks as follows:
addBlockTypesaction directly, a new__experimentalAddBlockTypeaction is called with the unprocessed block type. This action has two subactions:unprocessedBlockTypesreducer.registerBlockTypemethod before.__experimentalReapplyBlockTypeFiltersthat calls side-effects, that uses a new__experimentalGetUnprocessedBlockTypesselector to get all registered unprocessed block types and applies all current filters (including those registered later) and updates the list of processed block types.There is no impact at all to the result of performance tests included as GitHub workflow because there are no 3rd party blocks registered.
TODO
I still plan to measure if registering a big number of 3rd party blocks and filters would have a negative impact on the performance of__experimentalReapplyBlockTypeFiltersaction call and all the processing in the data control.See #34299 (comment).
Known Limitations
Ideally, we should be able to apply those filters at any time and all block definitions should magically update, but there are some architectural shortcomings that we would have to address first:
save,attributesorsupportsmight impact the result of parsing the same block.How has this been tested?
I registered a test block and a test filter in the wrong order to validate if the filter is going to be reapplied.
Types of changes
Bug fix (non-breaking change which fixes an issue).
Checklist:
*.native.jsfiles for terms that need renaming or removal).