Improve performance of global inserter: don't rerender on every attribute change.

[jorgefilipecosta]

Inserter withSelect passed many props that contain objects that change on every block attribute change e.g.: getBlocks. These props are used only on withDispatch. We changed the withSelect not to pass complete objects but just pass the properties that in fact, withDispatch uses.

How has this been tested?

Verify the global inserter still works as expected.
Use the highlight updates browser feature to check it does not rerender on every attribute change e.g: key press in a paragraph.

Screenshots

Before:

After:

[youknowriad]

I have memories of @aduth having a PR to refactor this using effects, but I'm not certain 🤷‍♂️

[aduth]

I have memories of @aduth having a PR to refactor this using effects, but I'm not certain 🤷‍♂️

Refactor which? I have dreams (and local in-progress branches) of a world without explicit index and root UID arguments, though they have yet to be realized in the form of a pull request. I might have similar ones though.

[jorgefilipecosta]

Thank you for clarifying this @aduth. In that case, do you think the changes here make sense or you think it is better to wait/work on bigger changes that remove the need for index and root uid arguments?

[aduth]

do you think the changes here make sense

I think there's value. I've certainly noticed the flickering Inserter button when React updates are highlighted while typing. I'd guess the overall impact is small: AFAICT it should only be the top-level Inserter component which is reconciling itself, not any of its descendants?

An alternative thought I'd had previously was maybe there'd be benefit in a higher-order component which omits certain props, since in cases like this (and others), we're injecting props which are only used in composition (selectedBlock from withSelect to withDispatch, but used no further).

See also: Recompose documentation mention of an omitProps implementation

I'm also a bit curious the cost comparison of calling isUnmodifiedDefaultBlock on every state change where a block is selected, which was not the case previously. It's not particularly trivial for the majority case where we're typing within a paragraph:

gutenberg/blocks/api/utils.js

Lines 26 to 42 in a5aad35

	export function isUnmodifiedDefaultBlock( block ) {
	const defaultBlockName = getDefaultBlockName();
	if ( block.name !== defaultBlockName ) {
	return false;
	}
	const newDefaultBlock = createBlock( defaultBlockName );
	const attributeKeys = applyFilters( 'blocks.isUnmodifiedDefaultBlock.attributes', [
	...keys( newDefaultBlock.attributes ),
	...keys( block.attributes ),
	] );
	return every( attributeKeys, ( key ) =>
	isEqual( newDefaultBlock.attributes[ key ], block.attributes[ key ] )
	);
	}

[jorgefilipecosta]

I'm also a bit curious the cost comparison of calling isUnmodifiedDefaultBlock on every state change where a block is selected, which was not the case previously. It's not particularly trivial for the majority case where we're typing within a paragraph.

That's, in fact, a disadvantage of this approach. I'm closing this PR as we are not certain if, in fact, it increases the performance.