As much as I love Reselect, I hold the crazy idea that Reselect creates a leaky abstraction by exposing its 2 lowest level API functions (createSelectorCreator anddefaultMemoize).

I think that if it didn't do that, then it would be possible to solve the problem of "shared-selectors" in a way that it would be almost transparent for the developer. I discuss that idea at length inthis post. Also, I have createdthis library just to make sure that what I'm about to suggest is not totally crazy.

The API that I would like to suggest for version 5 would be something like this:

• createSelector: same signature as today
• createStructuredSelector: like the current one, but removing its second parameter
• createKeySelector: an enhancer that lets the library know that the selector that is being enhanced returns an special type of result: the identifier of the instance(s) that consume the selector.

With that API it would be possible to solve the problem of shared selectors, just likeredux-views does.

Just in case that it is not obvious: I have not created Redux-Views to "compete" with Reselect. I did it just to show that it is possible to implement the API that I'm suggesting. If Reselect decides to go down this road (or a similar one) I would love to help and I would immediately deprecate Redux-Views, of course.