Check if key has been cached

[kasvtv]

I'm using this little lib a lot and find it extremely useful. However, I often find myself wanting to check whether or not something has already been received or not and let my program flow depend on that. Any chance this can be polled? A simple .has([args]) method would make me very happy.

[puzrin]

Hm... that's doable, but a bit strange for cache workflow that i imagined, when designed this lib. Could you explain your use cases? May be i missed something.

[kasvtv]

Yeah, I can imagine it sounds strange indeed. But the thing is that without knowing if the cached item is already available, I'm forced to first set my app state to loading, after which React will replace part of the view with a loading animation, then await the promise (which may instantly resolve in case the item was cached), then set my app state to the fetched data (or error), after which React will replace part of the view again with the fetched data.

It would be great to be able to short circuit all the loading logic when I can know beforehand if data is available.

[puzrin]

Usually, for best UI experience, "loading..." message is displayed not when data not exists, but when server replies is goes too long. Because if data not exists but reply is fast, blinking with "loading..." message would be annoying. So, in ideal world, checking cache state is not required.

May be you have more use cases?

[kasvtv]

Fair point. Still, whether that's better highly depends on the situation. There could be any reason a developer wants to do any arbitrary action if an actual network request was fired (or would be fired) or not. More sophisticated memoization libs (like fast-memoize) have this functionality as well, but I prefer this one for simplicity. I suppose it would only be a small change, would it not?

[puzrin]

would it not?

It's always a trade-off between simplicity and features. This package is intended to be simple, because of clear understanding how cache should work [in ideal world :smile:].

If you need more complex things, there is a memoizee package.

I tend to reject everything by default. But it's possible to consider new features when strong reasons available. Your current sample is a bit weak. I don't mean to teach you how to program, but would like to keep api simple, without strange features.

[kasvtv]

That is unfortunate. In theory, you can reject virtually any otherwise useful feature given an arbitrary workaround to solve the problem (regardless of whether it complies with the requirements of the user).

[puzrin]

I can't participate in abstract talks. I always ask use cases, to understand perspectives. And you are not limited add new samples, make a fork, or select something different.

[kasvtv]

So be it. You can close this issue. If you would ever consider adding such functionality, feel free to look at the fork I just made with these features.