@wordpress/data: Create useSelect hook.

[nerrad]

Description

See #15473 for background. The purpose of this pull is to do some experiments on a new useSelect hook. In this initial iteration:

• Signature is useSelect( storeName: string ): Object
• The hook receives a store name and will return an enhanced object of selectors from the store which themselves are hooks.

Example usage:

gutenberg/packages/editor/src/components/post-trash/check.js

Lines 1 to 15 in faa39a7

	/**
	* WordPress dependencies
	*/
	import { useSelect } from '@wordpress/data';
	export default function PostTrashCheck( { children } ) {
	const { isEditedPostNew, getCurrentPostId } = useSelect( 'core/editor' );
	const isNew = isEditedPostNew();
	const postId = getCurrentPostId();
	if ( isNew || ! postId ) {
	return null;
	}
	return children;
	}

Rationale:

• The api is fairly intuitive and easy to consume.
• In following the hook pattern, each selector on a store is enhanced to be itself a hook so that they are individually subscribed to changes in selector state. This eliminates the need to provide a mapSelectToProps callback (although I do think we'll want something like that... see notes later).
• Edit, this point and the example below actually break one of the rules of Hooks so it's not a valid point/example. Subscriptions are not set until a returned enhanced selector is invoked. This does allow for some lazy subscription registration on selector calls. Example:

const myComponent = ( propA ) => {
    const { mySelectorA, mySelectorB } = useSelect( 'mystore' );
    // a subscription is created for the mySelectorB call.
    const valueB = mySelectorB();
    let valueA = null;
    if ( propA === 'foo' ) {
          // subscription doesn't get set until this condition is met
          valueA = mySelectorA();
    }
    /** ... rest of logic for component **/
}

Some things to consider & potential drawbacks:

• Although subscriptions are not set until the enhanced selector is invoked, there is a bit more overhead involved than a single subscription created (as in withSelect). For instance, one of the concerns here is that with multiple selectHooks with resolvers, there's more re-rendering that could happen as each selector is resolved.
• I'm not certain if the async context is needed here but obviously this would need reworked if we want to retain that.
• Related to the previous point and the proposed signatures listed in Block Template Warning Missing in 5.2 #15743, we may want to offer the alternative mapSelectToProps option as that would reduce the number of registry subscriptions. However in the case of providing a mapSelectToProps, the returned object would be the props returned from the mapSelectToProps function. This version would be more similar to the current behaviour of withSelect
• It's convention that hooks have the use prefix. Although I didn't do that there, there's some advantages to returning our enhanced selectors with that prefix because it: 1. makes it clear these are hooks and should be treated as such. 2. Exposes them to the eslinting on hooks (which helps prevents incorrect usage - such as implementation order matters).

Todos:

• evaluate current approach, get feedback.
• implement additional signatures outlined in Data: Implement useSelect hooks corollary to withSelect #15473. I'm thinking it should be pretty consistent that if you provide a function it is assumed it is a mapSelectToProps like callback and if its a string, it's assumed to be a store name (and thus return the enhanced selectors on that store).
• Improve withSelect to incorporate a similar signature as what we land on for useSelect (although I don't think we need to strive for complete consistency because there is varying paradigms in play here).
• Add tests
• Pick a component which should help us gauge performance impact to refactor as a part of this work?
• Benchmarks (what existing benchmarking tools do we have for the project that can be used?).
• Changelog/docs.

Dependencies for this work:

• No matter what approach we take, there will be a dependency on @wordpress/data: Export entire registry context #15445 so that useContext for the registry is possible.

How has this been tested?

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.

[aduth]

Related discussion in Slack (link requires registration):

https://wordpress.slack.com/archives/C02QB2JS7/p1557341876475900

[nerrad]

one thing I'd like to explore here once #15436 is available, is if the selector has a resolver and the return is undefined then don't set the state. This would prevent unnecessary renders while the selector is resolving. It effectively would normalize undefined returns to null for all selectors with resolvers. That's one issue I've seen in the wild with withSelect currently in that unless the mapping function handles undefined results, re-renders are more frequent.

[nerrad]

Convention for hooks is kinda broken here, so I think I'll have to make sure that we return the custom enhanced selector hooks with the use prefix. So this would become something like:

const { useIsEditedPostNew, useGetCurrentPostId } = useSelect( 'core/editor' );

Necessary because otherwise it won't be obvious (without knowing the internals ) that these are in fact react hooks and thus the rules of Hooks apply to them.

[nerrad]

closing this in favour of the approach happening on #15737