Performance: optimize the usage of getBlockIndex #13067

youknowriad · 2018-12-21T20:08:29Z

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 · 2018-12-21T20:10:03Z

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 · 2018-12-21T20:10:57Z

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 · 2018-12-22T12:40:27Z

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 · 2019-01-02T20:48:47Z

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 · 2019-01-02T20:51:17Z

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 · 2019-01-21T11:09:27Z

Rebased this, can I get some reviews?

youknowriad · 2019-01-22T08:45:19Z

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

gziolo

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 · 2019-01-24T16:26:20Z

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 · 2019-01-24T16:27:35Z

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

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 · 2019-01-24T16:30:50Z

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 · 2019-01-24T16:41:31Z

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 · 2019-01-24T17:04:57Z

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

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

gziolo

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?

…rnmobile/372-add-enter-key-detection-to-title * 'master' of https://github.com/WordPress/gutenberg: Add new RSS Block (#7966) Performance: optimize the usage of getBlockIndex (#13067)

designsimply · 2019-01-25T19:14:57Z

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 · 2019-01-28T10:59:32Z

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

youknowriad added the [Type] Performance Related to performance efforts label Dec 21, 2018

youknowriad self-assigned this Dec 21, 2018

youknowriad requested a review from a team December 21, 2018 20:08

youknowriad commented Dec 21, 2018

View reviewed changes

youknowriad added this to the 4.9 milestone Dec 21, 2018

gziolo reviewed Dec 22, 2018

View reviewed changes

aduth reviewed Jan 2, 2019

View reviewed changes

youknowriad requested a review from a team January 8, 2019 07:43

aduth mentioned this pull request Jan 11, 2019

Editor: Update withDispatch-wrapped components to use registry if applicable #12890

Closed

4 tasks

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

youknowriad added 2 commits January 21, 2019 12:08

Performance: optimize the usage of getBlockIndex

d1aecb1

Small tweaks

94d8884

youknowriad force-pushed the update/get-block-index-performance branch from 860fec0 to 94d8884 Compare January 21, 2019 11:09

youknowriad added 3 commits January 21, 2019 15:35

Fix post rebase issue

8c706e9

Tweaks to the inserter

3de6e0c

Fix appender inserters

08b8b30

Fix unit tests

2d984c4

gziolo reviewed Jan 24, 2019

View reviewed changes

aduth approved these changes Jan 24, 2019

View reviewed changes

gziolo approved these changes Jan 24, 2019

View reviewed changes

youknowriad merged commit 4afda93 into master Jan 25, 2019

youknowriad deleted the update/get-block-index-performance branch January 25, 2019 09:04

This was referenced Feb 4, 2019

Bump plugin version to 5.0.0-rc.1 #13652

Merged

Bump plugin version to 5.0.0 #13689

Closed

Bump plugin version to 5.0.0 #13692

Merged

jorgefilipecosta mentioned this pull request Feb 21, 2019

Fix: Global inserter does not validates block insert restrictions #14020

Merged

youknowriad added a commit that referenced this pull request Mar 6, 2019

Performance: optimize the usage of getBlockIndex (#13067)

39936ed

youknowriad added a commit that referenced this pull request Mar 6, 2019

Performance: optimize the usage of getBlockIndex (#13067)

b475681

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Performance: optimize the usage of getBlockIndex #13067

Performance: optimize the usage of getBlockIndex #13067

youknowriad commented Dec 21, 2018 •

edited

Loading

youknowriad Dec 21, 2018

youknowriad Dec 21, 2018

gziolo Dec 22, 2018

aduth Jan 2, 2019

aduth Jan 2, 2019

aduth Jan 2, 2019

aduth Jan 2, 2019

youknowriad commented Jan 21, 2019

youknowriad commented Jan 22, 2019

gziolo left a comment

gziolo Jan 24, 2019

gziolo Jan 24, 2019

aduth left a comment

aduth Jan 24, 2019

aduth Jan 24, 2019

youknowriad Jan 24, 2019

youknowriad Jan 24, 2019

jasmussen Jan 25, 2019

youknowriad Jan 25, 2019

aduth Jan 24, 2019

aduth Jan 24, 2019

gziolo commented Jan 24, 2019

gziolo left a comment

designsimply commented Jan 25, 2019

gziolo commented Jan 28, 2019

Performance: optimize the usage of getBlockIndex #13067

Performance: optimize the usage of getBlockIndex #13067

Conversation

youknowriad commented Dec 21, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

youknowriad commented Jan 21, 2019

youknowriad commented Jan 22, 2019

gziolo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aduth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gziolo commented Jan 24, 2019

gziolo left a comment

Choose a reason for hiding this comment

designsimply commented Jan 25, 2019

gziolo commented Jan 28, 2019

youknowriad commented Dec 21, 2018 •

edited

Loading