@wordpress/data: Export entire registry context

[nerrad]

Description

As a part of the work being done on #15444, the useContext hook is being used to obtain the registry value from the context. However in order to do this the entire registry context object must be exposed from @wordpress/data. This pull does so.

This has utility for anywhere else where useContext might be implemented with the registry context.

How has this been tested?

• Cherrypicked into Refactor: Add data component for editor initialization to replace __unstableInitialize action. (fixes #15403) #15444 and verified it works as expected there.

Types of changes

This is a non-breaking change and is an enhancement exposing the entire RegistryContext object. Existing Consumer and Provider values are left alone so there's no impact to existing code.

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]

I think based on the availability of useContext and its usage pattern, we should want to expose this object anywhere we also expose the provider and consumer subcomponents. If agreeable, we should consider auditing and creating a tracking issue.

For confirmation, this capitalization (UpperCamelCase) does seem to be what is promoted by React in their documentation:

https://reactjs.org/docs/hooks-reference.html#usecontext

[aduth]

Can we make sure this is documented? See also #15176, which proposes documentation for RegistryConsumer and RegistryProvider.

[nerrad]

I forgot about this pull! I think we should actually either close this or rework it so that it instead just exposes the useRegistry hook instead of the entire context object (see https://github.com/WordPress/gutenberg/pull/15737/files#diff-f777130d04381cfeacdaeb4005e1f670) as a part of #15737.

[aduth]

@nerrad But useContext seems like something we should want to support for anywhere we're already providing a Consumer component, or do you disagree?

[nerrad]

But useContext seems like something we should want to support for anywhere we're already providing a Consumer component, don't you think?

In the case of for the registry, I think any implementation would just use useRegistry instead of useContext. Effectively the only reason for useContext( RegistryContext ) would be to return the same as what useRegistry would.

We'd still need to export RegistryProvider and RegistryConsumer both for back-compat and because RegistryProvider will still need to wrap any component tree implementing either the consumer or the useRegistry hook.

[aduth]

Okay, this seems like a good conservative default for now. My thinking was less about registry context specifically, but context consumers generally. I think we tend to not expose the consumers anyways (intentionally?), so no need to be premature with exposing the context object I suppose. The only potential downside is that if we do choose to have a generic pattern, we'd need to decide how to reconcile this with useRegistry. Either a useFoo for every context available, or inconsistency of useRegistry vs. useContext( FooContext ), or some legacy we have to carry with us.

[nerrad]

Either a useFoo for every context available, or inconsistency of useRegistry vs. useContext( FooContext ), or some legacy we have to carry with us.

Good points there, but I think context (a a general term, not an intentional pun!) matters here. I think we should generally avoid exposing low level things from wp.data unless demonstrated to be necessary and rather use available apis for exposing (which in this case would be useRegistry). I don't think we can come up with a blanket rule for all usages of Context across different packages.

[nerrad]

Fwiw, we probably could avoid exposing useRegistry as a public api initially too assuming it's just implemented in useSelect or useDispatch?

[nerrad]

This pull is now invalid. There is a useRegistry hook exposed in #15737 that has been merged.