How can the #ngrx/Store be used for caching? - ngrx

Question

Proponents of ngrx claim (here for example) that you can and should keep all your application state in a single Store. That would suggest the #ngrx/Store can be used for caching because the contents of the cache is a type of application state.
A cache in a web-application is a thing that returns data when it has it, and encapsulates the requesting of the data from the server when it doesn’t. The Wikipedia article on caching calls it a cache hit when the data is available and a cache miss when it isn't.
From a functional programming perspective we can immediately see that reading data from a cache is functionally-impure - it has a side-effect which is that data may be requested from the server and retained in the cache. I don't know how to do this with ngrx which, for example, requires its Selectors to be functionally-pure.
It might help to consider this Caching With RxJs Observables in Angular tutorial (rxjs is said to be extremely complementary to ngrx). We don't have to scroll far to find the getFriends() function complete with side-effect:
getFriends() {
if(!this._friends){
this._friends = this._http.get('./components/rxjs-caching/friends.json')
.map((res:Response) => res.json().friends)
.publishReplay(1)
.refCount();
}
return this._friends;
}
Also the contents of the Store seem to be universally available to the entire application. The only controls are on how the state can be updated, but it is foolish to go poking around in a cache's raw data unmediated because there are no guarantees about which cache items are available and which are not available.
Hopefully these concerns can be relieved and there's a way of doing this that I've missed. Please can you show me a good way to go about using #ngrx/Store as a cache?

Answer 1

You can do something like this
friends$ = createEffect (() =>{
this.actions$.pipe(
.ofType(ListActions.LOAD)
.withLatestFrom(
this.store.select(fromSelectors.loadedList),
(action: fromList.Load, store: fromList.State) => store.friends
)
.switchMap((friends: Friend[]) => {
if (friends) {
return [new ListActions.Loaded(friends)];
}
return this.http
.get('/friendApi')
.map((friends: Friend[]) => new ListActions.Loaded(friends))
.catch(err => Observable.of(new ListActions.Failed()));
});
}
With ‘withLatestFrom’ operator, we get the store (loaded list) state into our effect with the dispatched action and check if the list is filled if so; dispatch the existing list otherwise make the rest call and update our store in the reducer.
For a detailed answer refer to this Medium post

Answer 2

In ngrx there are reducers (pure functions) which change the state (or cache) if you will. Those reducers get triggered by actions which you dispatch on the store.
From the store you request slices of data by selectors and subscribe to their changes.
To implement a cache logic you check if data is available and if not you
dispatch an action like "LoadDataSliceAction" which would trigger a side Effect which then loads the data into the store.
Does this help?

Answer 3

It’s worth noting that browsers come with a cache as standard, and it’s the real deal, encapsulating requests and encapsulating data, because it possesses none of the limitations of nrgx discussed in the question.
We’re using the browsers cache for storing entities these days. Borrowing my definition from here:
An entity is an object with long-lived data values that you read from the server (and possibly write back to it).
Entity data is only one kind of application data. Configuration data, user roles, the user’s prior selections, the current state of screen layouts… these are all important data that may benefit from coding with standard ngrx techniques, but they’re not entities.
This usurps one of Redux's fundamental principles (ngrx being an implementation of Redux), namely that the ngrx store is the single source of truth of your whole application. Here we are saying something different. Here we are saying that the browser cache is the single source of truth for our entities, and the ngrx Store is the single source of truth for everything else (actually it's slightly worse than that: if an entity is editable, then the Store has to assume responsibility for it while it is being edited).
The basics are trivial. We set a version number and a cache age on the http response of our entities:
X-Version: 23
Cache-Control: max-age=86400
When we receive the http response we process its body exactly as we might have done before but we do not store it anywhere. We leave that up to the browser to do that for us, and if we need the data a second time we simply re-request it, and it arrives almost instantaneous because the browser serves it from its cache.
And if we see an entity with an out of date version, then we immediately re-request it, being sure to override the cache by setting Cache-Control: no-cache in the request headers. This ensures we are always working with the current version of the entity.
this.http.get<T>(
url,
{...options, headers: {'Cache-Control': 'no-cache'}}
)
But how do we know a version is out of date? We are fortunate in that our versioning system is very granular, so we don’t get updates very often. Updates to current version numbers come via a web socket which I wasn’t involved with programing. So bear in mind that we are blessed, and this approach may not work for you (at least without putting some serious thought into it), and there are only two hard things in Computer Science: cache invalidation and naming things ;-)
Also some vigilance is required as there are a couple of ways I am aware of that the browser cache can be accidentally disabled which obviously now has terrible potential as a performance drain:
Inside the debugger, e.g. there's a "Disable cache" check-box in Chrome DevTools.
A bad SSL certificate. If the browser doesn't trust the server then it's right not to be retaining the data received. This is only a problem in a test environment where it's tempting to cheat and respond to "your connection is not private" by clicking "advanced" and "proceed".
So how's that for a solution (it's not going to make everyone happy is it)? Ngrx cannot be used as a bona-fide cache, but the browser can!

Answer 4

There are two main approaches i have found. They both involve adding a timestamp to any sections of your store that need to expire. The first is to check the age in the selector function and if it exceeds the limit you just dispatch the retrieval action. This one is fairly straight forward using the createSelector syntax and having access to a store for dispatch. The other requires you to dispatch the retrieval action as normal then you check the age of the data in the effect prior to retrieval. This can be achieved by combining the sttore observable with something like combineLatest(https://medium.com/#viestursv/how-to-get-store-state-in-ngrx-effect-fab9e9c8f087)
Example for first option
createSelector(previousSelector, (item) => {
const now = new Date();
const limit = new Date(now.getTime() - (5 * 60000));
if (item.age < limit) {
this.store.dispatch(new getFreshDataAction());
}
});