Track the parent block to optimize hierarchy selectors#16392
Conversation
|
I fixed the memory leak in the parents reducer. It turns out that I discovered memory leaks in other reducers (byClientId and order), I won't be fixing those right now in this PR though. A generic fix would be good but it's not possible due to the fact that we track reusable blocks their as well. |
|
I think this should be ready and I'm noticing something between 2-5% performance improvement. |
| case 'REMOVE_BLOCKS': | ||
| action = { | ||
| ...action, | ||
| removedClientIds: getAllChildren( action.clientIds ), |
There was a problem hiding this comment.
Is there a specific reason we need to rename these properties from clientIds, rather than just "enhancing" the existing value to account for the cascade? Seems like it might make this a bit simpler to implement, since you wouldn't need the switch to vary the behavior.
There was a problem hiding this comment.
I've been caught off guard in several occasions because of this. The fact that the property don't contain the same value between reducers (selection and blocks), and also the difference between the action creator (which I tend to take a look at to understand the action) led me to this change.
It is still a different action but instead but I think the fact that we introduce a new key makes it less confusing.
There was a problem hiding this comment.
I get the motivation for this. It could, however, be pretty jarring for someone who notices the discrepancy and pulls up the definition of removeBlocks, since it clearly only returns clientIds in its payload.
Perhaps update removeBlocks to make that relationship clearer?
// actions.js
yield {
type: 'REMOVE_BLOCKS',
clientIds,
removedClientIds: undefined // Explain bla bla higher-order reducer
};In alternative, if we're really strict about action types, it would be more "correct" to let this higher-order reducer divert from one action type to a new one:
// reducer.js
if ( state ) {
switch ( action.type ) {
case 'REMOVE_BLOCKS':
action = {
type: DERIVED_TYPE_SIMILAR_TO_REMOVE_BLOCKS,
removedClientIds: …There was a problem hiding this comment.
Alternatively, with controls implementation, these days we could probably incorporate this into the action creator itself, rather than as a reducer enhancer. That way the logic is consolidated to one place.
| case 'REPLACE_BLOCKS': | ||
| return { | ||
| ...omit( state, action.replacedClientIds ), | ||
| ...mapBlockParents( action.blocks, state[ action.clientIds[ 0 ] ] ), |
There was a problem hiding this comment.
Re: My previous comment, I guess we still reference the original clientIds here. Can you clarify what you're doing here in referencing only the first of the original of the clientIds ?
There was a problem hiding this comment.
Basically we need the parent of the replaced blocks to assign it as parent of the inserted blocks. replacedClientIds contains more than just the "root" level which in theory could result in the wrong value here.
| it( 'can replace a child block', () => { | ||
| const existingState = deepFreeze( { | ||
| byClientId: { | ||
| clicken: { |
| for ( let i = 0; i < clientIds.length; i++ ) { | ||
| clientIds.push( ...state.order[ clientIds[ i ] ] ); | ||
| for ( let i = 0; i < result.length; i++ ) { | ||
| if ( state.order[ result[ i ] ] ) { |
There was a problem hiding this comment.
Is this condition related to your comment at #16392 (comment) with regards to orphaned references? Should we comment it as a temporary fix if it is meant to be temporary?
There was a problem hiding this comment.
no, to be completely honest, I tried but failed to find why this condition is necessary. When you remove an "empty paragraph" using backspace, there's a JS error that is triggered if you remove this condition.
| ...state, | ||
| [ action.clientId ]: action.toRootClientId || '', | ||
| }; | ||
| } |
There was a problem hiding this comment.
Minor: unneeded block around return statement.
| case 'REMOVE_BLOCKS': | ||
| action = { | ||
| ...action, | ||
| removedClientIds: getAllChildren( action.clientIds ), |
There was a problem hiding this comment.
I get the motivation for this. It could, however, be pretty jarring for someone who notices the discrepancy and pulls up the definition of removeBlocks, since it clearly only returns clientIds in its payload.
Perhaps update removeBlocks to make that relationship clearer?
// actions.js
yield {
type: 'REMOVE_BLOCKS',
clientIds,
removedClientIds: undefined // Explain bla bla higher-order reducer
};In alternative, if we're really strict about action types, it would be more "correct" to let this higher-order reducer divert from one action type to a new one:
// reducer.js
if ( state ) {
switch ( action.type ) {
case 'REMOVE_BLOCKS':
action = {
type: DERIVED_TYPE_SIMILAR_TO_REMOVE_BLOCKS,
removedClientIds: …| }, | ||
| }; | ||
|
|
||
| expect( getBlockHierarchyRootClientId( state, 56 ) ).toBe( '123' ); |
There was a problem hiding this comment.
Considering it's documented to return a value of type string, I feel like we should choose clientIds which allow us to test for this to be true.
gutenberg/packages/block-editor/src/store/selectors.js
Lines 484 to 486 in 21e2dce
| case 'REMOVE_BLOCKS': | ||
| action = { | ||
| ...action, | ||
| removedClientIds: getAllChildren( action.clientIds ), |
There was a problem hiding this comment.
Alternatively, with controls implementation, these days we could probably incorporate this into the action creator itself, rather than as a reducer enhancer. That way the logic is consolidated to one place.
…rnmobile/track-unsupported-blocks * 'master' of https://github.com/WordPress/gutenberg: Bump plugin version to 6.1.0-rc.1 Update HTML anchor explaination text (#16142) Move post permalink to beneath title on mobile. (#16277) Export cloneBlock method to the mobile (#16441) Fix inconsistent references to Settings Sidebar (#16138) Adds a cache key to the blocks reducer in order to optimize the getBlock selector (#16407) Track the parent block to optimize hierarchy selectors (#16392)
Extracted from #16368
This PR tracks the parent of a block in the "blocks.parents" state tree in the reducer to optimizer the performance of some block editor selectors.
On its own, this PR doesn't seem to have a huge impact on performance bit it's a good step towards #16368