RemoteCacher makes it simple to store remote data in your browser's native localStorage. While this is relatively simple to setup for a project, this can easily turn into the kind of boilerplate churn that no developer likes.
With RemoteCacher, you get a simple interface allowing you to return cached data or evict it. By infering what data is available, looking at the cache key's time-to-live and what params you pass, you don't have to deal with the drudgery of doing if/else
kind of code to determine if you need to grab new fresh data or return it, and so on.
- Import the script as per the
Loading the script
section in this document. - It's nicer to create a dedicated cache configuration object that you can reuse in case you need to run more frequent cache checks. For the format, see below.
- Call
RemoteCacher.cache(cacheConfig)
wherecacheConfig
is your cache configuration object. Also make sure toawait
your response since the function returns a promise. - The remote data will now be cached in localStorage together with a timestamp under the given
cacheKey
. Whenever you runRemoteCacher.cache(cacheKey)
(wherecacheKey
is an already cached key) you will get back the in-memory data instead of fetching it online again. - Note: It's going to be more resilient to run a full
RemoteCacher.cache(cacheConfig)
as the additional parameters will ensure that there is enough context for the function to actually get new data when the cache is expired. An expired cache, without the additional params, will result in an error being thrown. While this will happen (with default TTL) only once the cache has lived more than one hour, and may not affect you, it should be made clear from my end regardless. Beyond this resiliency factor, the functionality and caching is exactly the same.
Example
// Set up a configuration for your cache
// NB: You can use multiple configs/keys
const cacheConfig = {
cacheKey: 'features',
source: 'https://someurl.com/api/',
body: {
market: 'JP'
},
headers: {
method: 'POST'
Authorization: 'Bearer {abc123...}'
},
cacheTtl: 300
};
// NB: The function returns a promise, so it should be awaited
const cachedData = await RemoteCacher.cache(cacheConfig);
console.log(cachedData);
RemoteCacher
's primary function is named cache() which takes a configuration object.
RemoteCacher.cache({
cacheKey, // The key name (string) you want to use with localStorage; required
source, // An endpoint URL (string) to call with Fetch(); required when fetching new data (happens if cacheKey is empty or stale)
/* Other keys, and their defaults */
body = null, // Body to pass to Fetch(). Default is to not use any body.
headers = { method: 'GET' }, // Headers block to pass to Fetch(). Default is to GET data.
cacheTtl = 3600 // Cache time-to-live, specified in seconds. Default is 1 hour.
});
The secondary function of RemoteCacher
is evict().
This can be done per key with RemoteCacher.evict(cacheKey)
provided a given key, or with RemoteCacher.evict()
to clear the entirety of localStorage.
Load the script from unpkg with:
<script src="https://unpkg.com/remotecacher@1.0.4/dist/remotecacher.js"></script>
Or just use it old-school, by downloading the script and referencing it locally if you prefer.
You should be able to import it just fine, presumably with something normal-looking like import { cache, evict } from 'remotecacher'
. Do a pull request if there is something with the import that's flaky and needs work.
Run yarn dev
or npm run dev
to start a development server. It will mount the Javascript into src/index.html
which is a very simple frame for validating or testing your functionality.
Run yarn build
or npm run build
and it will use Webpack to bundle a UMD build into the dist
folder. Supported browsers can be seen below.
Note that the template/demo HTML page in /src
will not be bundled when building.
I've compiled the distribution code with the following .browserslist
settings:
Chrome >= 77
Safari >= 12
iOS >= 11
Firefox >= 70
Edge >= 15
> 5%
not IE 11
At the time of doing version 1.0.0
, this had global coverage of 76.89%.
None right now.
- Investigate if there is a need for "sticky" functionality on the
RemoteCacher
end, so for example A/B type values do not suddenly reset or change