Question: is the string or number restriction necessary if using a custom cacheObject? about re-reselect HOT 4 CLOSED

Hi @ianobermiller,
currently the string|number limitation is imposed at the core level of the library.

Therefore custom cacheObject instances can only receive cache keys of type number or string.

Updating the library to let in any kind of cache key value is technically feasible but it's something I'd like to consider very carefully.

Do you have any significative use case for it?

Cheers!

from re-reselect.

Ping @ianobermiller. 😄
I came up with a possible solution to move the string/number restriction from the library to the cache implementation. Here is the work in progress PR #37.

I still cannot think of a real use case for it, but it's probably just me. BTW, happy to receive any feedback.

Cheers!

from re-reselect.

Hey! Sorry for that, not sure how I missed your original response! The use case was that we have an expensive computation that it done on an object in the redux store, and we want the entire object itself to be the key because there is no other identifier. Our case was something like transforming a JSON representation of rich text into the JSX needed to render it (or just from one format used for storage to another used for rendering).

from re-reselect.

Shipped with v2.0.0!

from re-reselect.