Size Change: +576 B (0%)

Total Size: 1.21 MB

_{compressed-size-action}

@youknowriad, what was the reason createRegistrySelector was introduced in the first place? Is it possible that it is used too often these days?

I don't remember exactly the original reasons but I do know we use it for at least two things:

• we did several refactorings: moving from core/editor to core/block-editor for blocks, moving from core/editor to core/data for entities and with these core/editor selectors need to call selectors from other stores.
• Initiall isResolving calls were not store specific, we had a common store that tracked resolution state for all the other stores and isResolving from a high-level store were calling the lower level store selectors.

I don't remember exactly the original reasons but I do know we use it for at least two things:

• we did several refactorings: moving from core/editor to core/block-editor for blocks, moving from core/editor to core/data for entities and with these core/editor selectors need to call selectors from other stores.
• Initiall isResolving calls were not store specific, we had a common store that tracked resolution state for all the other stores and isResolving from a high-level store were calling the lower level store selectors.

Yes, it all makes sense to use createRegistrySelector for backward compatibility. Do you think, we should refactor all usage of selectors that use this helper as a way to proxy other selectors? My assumption is that if we use createRegistrySelector as a way to proxy deprecations then we don't use them in Gutenberg which makes it possible to find a way to make store specific useStoreSelectors react only to updates scoped to its own store. In fact, we could update the implementation of createRegistrySelector to make it possible for useStoreSelectors to behave like an isolated store until a first call of the selector wrapped with this helper happens. When the createRegistrySelector wrapped selector is called, it would enable backward compatibility mode that listens to updates in all stores.

Do you think, we should refactor all usage of selectors that use this helper as a way to proxy other selectors?

What do you mean? these are already proxy selectors.

I also think we have use-cases where we want to combine results from several stores in a single selector.

I also think we have use-cases where we want to combine results from several stores in a single selector.

Couldn't those be replaced with editor-specific react hooks? This way they wouldn't have to be exposed as a public API by default. And no registry selectors = less overall complexity.

Do you think, we should refactor all usage of selectors that use this helper as a way to proxy other selectors?

What do you mean? these are already proxy selectors.

There are more selectors like the following:

I added some relevant considerations in #26692 (comment) - let's move the discussion there?

Closing for now (see #26692 (comment)).