In the previous part of this series we discussed optimistic updates and how to avoid some traps when using them.
In this part we will cover caching.
What is caching?
Caching is a way to improve performance of an operation by saving its result somewhere, which can be retrieved later when needed instead of repeating the same operation again. One of such operation can be AJAX request, which is worth caching if possible, because with caching we can decrease communication with server. This not only could make our app much more responsive, especially on mobile devices, but also would decrease our server load.
When to cache?
Of course you cannot usually cache everything. Sometimes you cannot afford to do it, because you might need a fresh data from your server all the time. But if data is static, or relatively static and you could consider caching something even for a small period of time, if might be worth it, especially for slow networks or endpoints, or if a request could be repeated many times in a short period of time.
Caching with redux-requests
To activate it, just pass cache: true
to handleRequests
:
import { handleRequests } from '@redux-requests/core';
handleRequests({
...otherOptions,
cache: true,
});
After this, you can use meta.cache
in request actions:
const fetchBooks = () => ({
type: FETCH_BOOKS,
request: { url: '/books'},
meta: {
cache: 10, // in seconds, or true to cache forever
},
});
What will happen now is that after a succesfull book fetch (to be specific after FETCH_BOOKS_SUCCESS
is dispatched), any FETCH_BOOKS
actions for 10
seconds won't trigger any AJAX calls and the following FETCH_BOOKS_SUCCESS
will contain previously cached server response. You could also use cache: true
to cache forever.
Cache with cacheKey
Sometimes you would like to invalidate your cache based on a key, so if a key is changed, then you would bypass the cache and network would be hit. You can use meta.cacheKey
for that:
const fetchBooks = language => ({
type: FETCH_BOOKS,
request: { url: '/books', params: { language } },
meta: {
cache: 10,
cacheKey: language, // if language changes, cache won't be hit and request will be made
},
});
Cache with requestKey
Another use case is that you might want to keep a separate cache for the same request action based on a key. Then, like for usual not cached queries, you could use meta.RequestKey
. For example:
const fetchBook = id => ({
type: FETCH_BOOK,
request: { url: `/books/${id}`},
meta: {
cache: true,
requestKey: id,
},
});
/* then, you will achieve the following behaviour:
- GET /books/1 - make request, cache /books/1
- GET /books/1 - cache hit
- GET /books/2 - make request, cache /books/2
- GET /books/2 - cache hit
- GET /books/1 - cache hit
*/
cacheKey
and requestKey
together
You can also use cacheKey
and requestKey
at the same time, then different cacheKey
will be able to invalidate cache for each requestKey
individually, like:
const fetchBook = (id, language) => ({
type: FETCH_BOOK,
request: { url: `/books/${id}`, params: { language } },
meta: {
cache: true,
cacheKey: language,
requestKey: id,
},
});
/* then, you will achieve the following behaviour:
- GET /books/1?language=en - make request, cache /books/1
- GET /books/1?language=en - cache hit
- GET /books/2?language=de - make request, cache /books/2
- GET /books/2?language=en - make request, cache /books/2 again due to changed language
- GET /books/2?language=en - cache hit
*/
There is an interesting requestKey
and cacheKey
relation. Passing the same requestKey
and cacheKey
is the same like passing only requestKey
, because requests are stored separately for each requestKey
, so cache invalidation with the same cacheKey
could never happen.
Cache with requestCapacity
When you use cache
with requestKey
, like without caching you can be worried about storing too many queries in state. You can use requestsCapacity
to prevent that:
const fetchBook = id => ({
type: FETCH_BOOK,
request: { url: `/books/${id}`},
meta: {
cache: true,
requestKey: id,
requestsCapacity: 2,
},
});
/* then, you will achieve the following behaviour:
- GET /books/1 - make request, cache /books/1
- GET /books/1 - cache hit
- GET /books/2 - make request, cache /books/2
- GET /books/2 - cache hit
- GET /books/1 - cache hit
- GET /books/3 - make request, cache /books/3, invalidate /books/1 cache
- GET /books/1 - make request, cache /books/1, invalidate /books/2 cache
*/
Manual cache clearing
If you need to clear the cache manually for some reason, you can use clearRequestsCache
action:
import { clearRequestsCache } from '@redux-requests/core';
// clear the whole cache
dispatch(clearRequestsCache());
// clear only FETCH_BOOKS cache
dispatch(clearRequestsCache([FETCH_BOOKS]));
// clear only FETCH_BOOKS and FETCH_AUTHORS cache
dispatch(clearRequestsCache([FETCH_BOOKS, FETCH_AUTHORS]));
Note however, that clearRequestsCache
won't remove any query state, it will just remove cache timeout so that the next time a request of a given type is dispatched, AJAX request will hit your server. So it is like cache invalidation operation. To remove also data you can use resetRequests
action.
What's next?
In the next part we will touch imperfect world in which we live, when frontend developer is expected to start working on a feature even if backend is not yet ready.
Top comments (0)