Description

Minimize the calls of the selectors in useSelect by only subscribing to the stores needed.

The problem

Currently, useSelect works by subscribing to the registry instance and calls the mapSelect (the first argument of useSelect) function every time the store changes. It works fine, but it also fires many unnecessary mapSelect calls when we know that the store updates won't cause a re-render.

Most components subscribe to the default registry, and most stores also registered to that same registry. Let's say that some component has a counter store and multiple other stores like core, core/editor, core/block-editor, etc. The counter store has a selector getCounter, which simply gets the count state from the store. A component using this selector could look like this.

function TestComponent() {
	const { count } = useSelect( select => ({
		count: select( 'counter' ).getCounter(),
	}), [] );

	return count;
}

It's clear that this component doesn't care about state updates from stores other than counter. However, the selector still gets called when we dispatch any actions no matter if the action doesn't belong to the counter store.

Fortunately, since the count state from getCounter() doesn't change, <TestComponent> doesn't have to re-render. Still, it's an unnecessary call of the getCounter selector. In this specific case, it doesn't matter much, but it would matter if the mapSelect function is very complex or slow. Especially when we have resolver for each selector, which could potentially cause unwanted side-effects to be introduced.

The solution

This PR propose a solution to minimize the calls of the mapSelect function as much as possible. The idea is to only call the mapSelect function if and only if the store this mapSelect has referenced to gets updated.

For instance,

useSelect( select => ({
	count: select( 'counter' ).getCounter(),
}), [] );

this useSelect only cares about updates within the counter store itself and nothing else. We only have to re-run the mapSelect function whenever the state from the counter store updates.

Another example,

useSelect( select => ({
	count: select( 'counter' ).getCounter(),
	isPublished: select( 'core/editor' ).isCurrentPostPublished(),
}), [] );

this useSelect cares about state updates from two different stores: counter and core/editor. Whenever either one of the store updates, we need to re-run the mapSelect function.

This is done by trapping the select function of the registry to keep track of every store it has called. It works very similarly like monkey-patching the select function as follow (the actual implementation is slightly different because of some issues with legacy features with use and withPlugins):

const listeningStores = [];

const originalSelect = registry.select;
registry.select = function trapSelect( storeKey ) {
	listeningStores.push( storeKey );
	return originalSelect.call( this, storeKey );
};

Whenever reigstry.select( storeKey ) is called, we'll push the storeKey to the listeningStores. Later, we can then only subscribe to those stores rather than subscribing to the whole registry.

- registry.subscribe( onChange );
+ listeningStores.forEach( storeKey => registry.stores[ storeKey ].subscribe( onChange ) );

How has this been tested?

Added a bunch of unit tests and also fixed some tests.
End-to-end tests should also be passing.

Performance tests

>> post-editor

┌─────────┬───────────┬────────────┬────────────┬─────────────┬─────────────┬────────────┬─────────────┐
│ (index) │   load    │    type    │  minType   │   maxType   │    focus    │  minFocus  │  maxFocus   │
├─────────┼───────────┼────────────┼────────────┼─────────────┼─────────────┼────────────┼─────────────┤
│ This PR │ '6733 ms' │ '44.5 ms'  │ '40.78 ms' │ '100.23 ms' │ '98.93 ms'  │ '73.53 ms' │ '131.48 ms' │
│ master  │ '7360 ms' │ '53.59 ms' │ '46.28 ms' │ '113.3 ms'  │ '105.19 ms' │ '65.89 ms' │ '143.31 ms' │
└─────────┴───────────┴────────────┴────────────┴─────────────┴─────────────┴────────────┴─────────────┘

>> site-editor

┌─────────┬──────────────┐
│ (index) │     load     │
├─────────┼──────────────┤
│ This PR │  '1243 ms'   │
│ master  │ '1255.33 ms' │
└─────────┴──────────────┘

As seen in the report, this PR out-performs every test. However, the difference is not that big though, it might be just a micro-optimization in the end.

Types of changes

New feature

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR.