Performance: optimize the usage of getBlockIndex #13067

youknowriad · Dec 21, 2018

When adding blocks or pressing "Enter", the index of the blocks following the insertion point changes which means all the blocks following this block rerender because they have the order as a prop.

In this PR, I move the getBlockIndex selector usage to the event handlers instead of computing it in withSelect and passing it as a prop to the component to avoid heavy rerenders when pressing "Enter".

youknowriad · Dec 21, 2018

youknowriad reviewed Dec 21, 2018

View changes

youknowriad · Dec 21, 2018

packages/editor/src/components/block-list/block.js

@@ -769,6 +773,7 @@ const applyWithDispatch = withDispatch( ( dispatch, ownProps, { select } ) => {
 } );

 export default compose(
+	pure,


This is useful to avoid rerendering all the blocks when we add/remove a block in the block list (parent component).

I was also tempted to replace it with React.memo as it may be more optimized than our HoC. It would be good to compare performance of these two.

youknowriad · Dec 21, 2018

youknowriad reviewed Dec 21, 2018

View changes

youknowriad · Dec 21, 2018

packages/editor/src/components/block-list/index.js

@@ -189,7 +189,6 @@ class BlockList extends Component {
 				{ map( blockClientIds, ( clientId, blockIndex ) => (
 					<BlockListBlock
 						key={ 'block-' + clientId }
-						index={ blockIndex }


I spent 2 hours trying to find why the blocks were rerendering, it turns out we had a useless prop (that was not even used :P)

gziolo · Dec 22, 2018

gziolo reviewed Dec 22, 2018

View changes

gziolo · Dec 22, 2018

packages/editor/src/components/block-actions/index.js

 			isLocked: !! getTemplateLock( rootClientId ),
 			blocks,
 			canDuplicate,
 			rootClientId,
 			extraProps: props,
 		};
 	} ),
-	withDispatch( ( dispatch, props ) => {
+	withDispatch( ( dispatch, props, { select } ) => {


@aduth - I don't see it on the list in #12890.

Anyways, I'm happy seeing that select is helping us to improve performance. We still didn't discover any downsides which is encouraging to do more refactoring like this.

@aduth - I don't see it on the list in #12890.

I think it was missed because I was explicitly looking for withDispatch( ( dispatch, ownProps ) or withDispatch( ( dispatch, {. We apparently have more variation 😬

I think it was missed because I was explicitly looking for withDispatch( ( dispatch, ownProps ) or withDispatch( ( dispatch, {. We apparently have more variation 😬

This is the only occurrence of the second argument being named as "props" for withDispatch, and best I could tell (by a regular expression search of withDispatch\( \( dispatch, [^{o]) there are no other variations.

aduth · Jan 2, 2019

aduth reviewed Jan 2, 2019

View changes

aduth · Jan 2, 2019

packages/editor/src/components/inserter/index.js


 		return {
 			title: getEditedPostAttribute( 'title' ),
 			hasItems: hasInserterItems( rootClientId ),
-			rootClientId,
-			index,
+			rootClientId: rootClientId || getBlockInsertionPoint().rootClientId,


Should this have been changed from rootClientId, ? There's redundancy here in that the same fallback behavior occurs a few lines above.

aduth · Jan 2, 2019

packages/editor/src/components/inserter/menu.js

 		const {
 			__experimentalFetchReusableBlocks: fetchReusableBlocks,
 			showInsertionPoint,
 			hideInsertionPoint,
 		} = dispatch( 'core/editor' );

+		// eslint-disable-next-line no-restricted-syntax


We should have a "Disable reason" if only to clarify what's actually being disabled here, given that no-restricted-syntax is an umbrella rule containing many miscellaneous custom rules.

youknowriad · Jan 21, 2019

Rebased this, can I get some reviews?

youknowriad · Jan 22, 2019

Updated to fix the tests and this actually also fixes #13349 :)

gziolo · Jan 24, 2019

gziolo reviewed Jan 24, 2019

View changes

This is a quite complex PR. I reviewed it but I was not able properly validate changes in packages/editor/src/components/inserter/menu.js file. I wIll try again after I play with PR in the browser.

Everything else seems to be correct. It's hard to follow as there are some changes in the props passed.

gziolo · Jan 24, 2019

packages/editor/src/components/block-drop-zone/index.js

 		return {
 			isLocked: !! getTemplateLock( rootClientId ),
 			getClientIdsOfDescendants,
+			getBlockIndex,


I assume that it isn't something we can handle using withDispatch and select call.

gziolo · Jan 24, 2019

packages/editor/src/components/block-drop-zone/index.js

@@ -101,6 +102,7 @@ class BlockDropZone extends Component {
 			return;
 		}

+		const dstIndex = dstClientId ? getBlockIndex( dstClientId, dstRootClientId ) : undefined;


What dst stands for? It would read better if we would avoid such abbreviations.

aduth · Jan 24, 2019

aduth approved these changes Jan 24, 2019

View changes

Looks good. Nice improvements 👍

This was difficult to review because it wasn't easy to associate individual changes with their goal, as there appears to be about a dozen separate goals of this pull request.

aduth · Jan 24, 2019

packages/editor/src/components/inserter/menu.js

+				getBlockSelectionEnd,
+				getBlockOrder,
+			} = select( 'core/editor' );
+			const { clientId, rootClientId, isAppender } = ownProps;


I don't really understand the purpose of this new isAppender prop. Isn't it enough to assume that if the inserter is not provided a clientId and there's no current selection, it should take the appending behavior to the rootClientId?

Okay, looking more, I think I understand it a bit better, particularly when the last block is not a paragraph and you have a selection, it's important that the inserter which is shown at the end of content would insert by appending, not after whatever selection happens to exist. The alternative would be that the default appender at the end of content provides the clientId of the last block, but I think the expressiveness of this new prop is preferable.

Also sometimes, there's no block inside a container block with an appender, and the currently selected block is elsewhere on the page, which means the regular flow would insert the new block under the selected block and not inside the container block.

Technically speaking, I'd love to remove the behavior we have where we insert a block after the selected block, it could be considered confusing and there's the in-between inserters to solve the same use-case.

I won't do it in this PR but would love thoughts cc @jasmussen

Technically speaking, I'd love to remove the behavior we have where we insert a block after the selected block, it could be considered confusing and there's the in-between inserters to solve the same use-case.

Followup question to this: if you used the Add Block button in the top toolbar on a very long page, where would the block be inserted? If the answer is "at the end", it doesn't seem like a good solution. Performance is important, of course, but is there any other way we can do it?

Most word processors insert non-text content where the caret is at. Honestly with the sibling inserter is a new solution with limited prior art. I understand it's a different beast, but we should still not trivially remove this. @alexislloyd what are your thoughts?

I was asking for thoughts and I have them, thanks @jasmussen :)

My impression was that sometimes, the behavior was not well-understood/confusing for some people but I totally agree that the technically matters shouldn't dictate the decision here, as it's not a big drawback to support this.

aduth · Jan 24, 2019

packages/editor/src/components/inserter/menu.js

+			}
+
+			// If there a selected block, we insert after the selected block.
+			const end = getBlockSelectionEnd();


getBlockSelectionEnd is performant enough, but there are optimization opportunities here to avoid calling it when isAppender is true (allow the short-circuiting of the following condition's ! isAppender).

let end; if ( ! isAppender && ( end = getBlockSelectionEnd() ) ) { const selectedBlockRootClientId = getBlockRootClientId( end ) || undefined; return { index: getBlockIndex( end, selectedBlockRootClientId ) + 1, rootClientId: selectedBlockRootClientId, }; }

Or:

if ( ! isAppender ) { const end = getBlockSelectionEnd(); if ( end ) { const selectedBlockRootClientId = getBlockRootClientId( end ) || undefined; return { index: getBlockIndex( end, selectedBlockRootClientId ) + 1, rootClientId: selectedBlockRootClientId, }; } }

Oh, I forgot this is only called on specific user interactions, not in a withSelect, so not nearly as big a deal.

gziolo · Jan 24, 2019

Updated to fix the tests and this actually also fixes #13349 :)

I can confirm that it fixes #13349! Nice one :)

gziolo · Jan 24, 2019

gziolo approved these changes Jan 24, 2019

View changes

In my testing, everything works great in comparison to master. It's even better because of this bug fixed.

I spent time trying to figure out why there is no appender after the last block is a Paragraph with content, but it seems like a design decision. @jasmussen is it explained somewhere?

designsimply · Jan 25, 2019

I spent time trying to figure out why there is no appender after the last block is a Paragraph with content, but it seems like a design decision. @jasmussen is it explained somewhere?

@gziolo perhaps this? #3078 (comment)

gziolo · Jan 28, 2019

It's slightly older I think but thanks for checking :)

youknowriad added the [Type] Performance label Dec 21, 2018

youknowriad self-assigned this Dec 21, 2018

youknowriad requested a review from WordPress/gutenberg-core Dec 21, 2018

youknowriad added this to the 4.9 milestone Dec 21, 2018

youknowriad requested a review from WordPress/gutenberg-core Jan 8, 2019

aduth referenced this pull request Jan 11, 2019
Closed
Editor: Update withDispatch-wrapped components to use registry if applicable #12890
4 of 4 tasks complete

youknowriad modified the milestones: 4.9 (Gutenberg), 5.0 (Gutenberg) Jan 21, 2019

youknowriad added some commits Dec 21, 2018

Performance: optimize the usage of getBlockIndex

d1aecb1

Small tweaks

Loading status checks…

94d8884

youknowriad force-pushed the update/get-block-index-performance branch from 860fec0 to 94d8884 Jan 21, 2019

youknowriad added some commits Jan 21, 2019

Fix post rebase issue

Loading status checks…

8c706e9

Tweaks to the inserter

Loading status checks…

3de6e0c

Fix appender inserters

Loading status checks…

08b8b30

Fix unit tests

Loading status checks…

2d984c4

youknowriad merged commit 4afda93 into master Jan 25, 2019
1 check passed

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

youknowriad deleted the update/get-block-index-performance branch Jan 25, 2019

This was referenced Feb 4, 2019

Merged

Bump plugin version to 5.0.0-rc.1 #13652

Closed

Bump plugin version to 5.0.0 #13689

Merged

Bump plugin version to 5.0.0 #13692

jorgefilipecosta referenced this pull request Feb 21, 2019
Open
Fix: Global inserter does not validates block insert restrictions #14020

WordPress/gutenberg

Join GitHub today

Performance: optimize the usage of getBlockIndex #13067

Conversation

youknowriad commented Dec 21, 2018 • edited

youknowriad added the [Type] Performance label Dec 21, 2018

youknowriad self-assigned this Dec 21, 2018

youknowriad requested a review from WordPress/gutenberg-core Dec 21, 2018

youknowriad reviewed Dec 21, 2018 View changes

This comment has been minimized.

youknowriad reviewed Dec 21, 2018 View changes

This comment has been minimized.

youknowriad added this to the 4.9 milestone Dec 21, 2018

gziolo reviewed Dec 22, 2018 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

aduth reviewed Jan 2, 2019 View changes

This comment has been minimized.

This comment has been minimized.

youknowriad requested a review from WordPress/gutenberg-core Jan 8, 2019

aduth referenced this pull request Jan 11, 2019

youknowriad modified the milestones: 4.9 (Gutenberg), 5.0 (Gutenberg) Jan 21, 2019

youknowriad added some commits Dec 21, 2018

youknowriad force-pushed the update/get-block-index-performance branch from 860fec0 to 94d8884 Jan 21, 2019

This comment has been minimized.

youknowriad commented Jan 21, 2019

youknowriad added some commits Jan 21, 2019

This comment has been minimized.

youknowriad commented Jan 22, 2019

gziolo reviewed Jan 24, 2019 View changes

gziolo left a comment

This comment has been minimized.

This comment has been minimized.

aduth approved these changes Jan 24, 2019 View changes

aduth left a comment

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

gziolo commented Jan 24, 2019

gziolo approved these changes Jan 24, 2019 View changes

gziolo left a comment

Hide details View details youknowriad merged commit 4afda93 into master Jan 25, 2019 1 check passed

1 check passed

youknowriad deleted the update/get-block-index-performance branch Jan 25, 2019

daniloercoli added a commit that referenced this pull request Jan 25, 2019

This comment has been minimized.

designsimply commented Jan 25, 2019

This comment has been minimized.

gziolo commented Jan 28, 2019

This was referenced Feb 4, 2019

jorgefilipecosta referenced this pull request Feb 21, 2019

youknowriad commented Dec 21, 2018 •

edited

youknowriad reviewed Dec 21, 2018

View changes

youknowriad reviewed Dec 21, 2018

View changes

gziolo reviewed Dec 22, 2018

View changes

aduth reviewed Jan 2, 2019

View changes

youknowriad force-pushed the update/get-block-index-performance branch from `860fec0` to `94d8884` Jan 21, 2019

gziolo reviewed Jan 24, 2019

View changes

aduth approved these changes Jan 24, 2019

View changes

gziolo approved these changes Jan 24, 2019

View changes

youknowriad merged commit `4afda93` into master Jan 25, 2019
1 check passed