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.

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

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.

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.

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.

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

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