Configure cache storage

[BigBadAlien]

Cache works pretty well if we need to store something while an application is running. But what if we want to keep cache after page reload? Do we have any way to do it?

We can handle it on onRequest interceptor but would be great to use the default cache feature. Any cons or thoughts of configuring storage for cache, like 'localStorage', 'memory', 'worker', etc...?

[BigBadAlien]

@klis87 What do you think? I can fork the repo, but want to understand possible edge cases, and is it possible to add the feature to one of the next versions

[klis87]

I will try to reply to you tomorrow, thank you for your question, actually this is something I already wanted to add to the core, but didn't just yet... due to those edge cases you mentioned :)

[klis87]

@BigBadAlien so, coming back to discussion, I already wanted to implement it, the API would be just requestAction.meta.cachePersist: boolean, but unfortunately I have other things to implement first, before this could work across all the cases. What are problems to solve?

1. The most important is just queries normalisation, for normalized queries we would need to also cache normalizedData in localStorage or alike, because caching query.data alone doesn't include objects data. I won't even try to fix this, because I started to work some time ago at better normalisation logic, because the current one has performance issues regarding checking if denormalizing has to be done or not. Actually on a dev branch I finished this, but... figured out there is a very another important improvement for normalisation feature, that yet again requires a change of algorythm. This is the main blocker and will be a killer feature, but I need quite much time to design the algorythm and implement it, which kinds of blocks everything else.
2. Another problem is SSR support, I want persistent cache to be compatible.
3. We need to make sure that this is compatible with mutations, if you mutate a query, this of course has to propagate to a persistent storage.
4. I am not sure, but it is possible, that it would be a little problematic for interceptors (some handlers like getData called on already transformed query etc), I designed new interceptors, but its development was postponed again due to 1)

I have a good news though, for a simple case, ignoring normalisation, this should be quite easy to implement with a custom redux middleware, you don't need to fork the library, as probably this would be also implemented as a custom middleware in the core. Please let me know if you need some help or ideas.

[BigBadAlien]

Thanks! A bit more complex than I expected lmao

Regarding middleware, yes, it's pretty clear.

Looking forward for the changelog