-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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.
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
Display children of inner block controllers in the block navigator #24083
Display children of inner block controllers in the block navigator #24083
Conversation
Size Change: +62 B (0%) Total Size: 1.16 MB
ℹ️ View Unchanged
|
I don't like this selector argument tbh, but I can live with it :). I commented about a potential bug though. |
e29a327
to
64a40e8
Compare
After some reports of typing performance regressions on 8.8 I used gitbisect and it seems that this PR introduced a big performance regression. |
@@ -67,10 +67,11 @@ export default compose( | |||
} = select( 'core/block-editor' ); | |||
const selectedBlockClientId = getSelectedBlockClientId(); | |||
return { | |||
rootBlocks: getBlocks(), | |||
rootBlocks: getBlocks( '', { includeControlledInnerBlocks: true } ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Calling selectors with inline objects is never a good idea in terms of performance, not sure it's the source of the issue but it's definitely something to avoid in general (breaks memoization)
? EMPTY_ARRAY | ||
: getBlocks( state, clientId, { | ||
includeControlledInnerBlocks, | ||
} ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This call also breaks memoization as it will recompute getBlocks on each call since we're passing and inline object.
return map( getBlockOrder( state, rootClientId ), ( clientId ) => | ||
getBlock( state, clientId ) | ||
getBlock( state, clientId, { includeControlledInnerBlocks } ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here.
The good news is that this PR fixes the regressions #24835 |
Thank you for the tips about inline objects, I did not realize that would be the case! |
Description
Fixes #23459. In #21368, all "controlled" inner blocks were excluded from
getBlock
andgetBlocks
. This works because much of the time, you only want to know whhat blocks are in the particular entity you are looking at. For example, when you callgetBlock
on a template part, you would not want to be aware of any children template parts. You only want to know which blocks are contained in that template part.However, there are still some bits of the UI (like the block navigator) which depend on seeing a list of all the blocks rendered on the page -- it does not care which blocks belong to which entity. So this PR:
getBlock
andgetBlocks
. Previously, those functions always excluded the children of nested inner block controllers. Now, these functions can include those nested children if a flag is set.BlockNavigation
to include all blocks, including nested inner block controller children.How has this been tested?
Locally, in edit site.
Screenshots
Types of changes
Bug fix
Checklist: