Question about "No weak-mappable object"

[nohira]

Hi,

Thanks for your library and documentation. It's very nice to find a library which explains what and how it solves some cache performance issues.
I've fully understood how it works now. All my arguments are objects and there is no non weak mappable objects as arguments when I call my selector.

I still have an issue concerning a selector which compute a result from multiple sub selectors which return all non weak mappable object (all booleans), and have an error.

In your documentation, you mention to use an external cache object but I guess, it should not be a global object that will never be unreferenced as it cache will never be cleared.

If I understand well, it will be better to have a weak mappable object, which also have his lifecycle and will be garbage collected to have my values being cached while this object still exist.

Am I right?

[theKashey]

Yes, you are correct.
The idea is to have an unique object, you can use as key for computations. The problem is - only one such object could be used as a key, so when times comes to "compose" different keys together memoization might fall (I should provide a helper to mitigate this).

However, sooner or later, you might end with all non weak mappable object (all booleans), or numbers/strings. That's ok, but do you need memoization for those calculations? Is there any complex medium to work out - all inputs are simple.

I know - some string calculations, as well as Fibonacci numbers, could be very CPU intense, but you will have use other memoization technology, with explicits cache, to handle them, not kashe.
That's the hard limitation of this library. Which makes your live easier.

There is also a case, when you are returning an object from such "complex" function - const getResult = (a,b) => ({a,b}) - and want that object to be "constant". Just use lodash, not try to overthink it - usually there are limited number of combinations, and you would experience no problem with the cache. 🤞