@pedro-rodalia/vuex-cache
Configurable Vue.js cache plugin for axios using the vuex store.
Install
Install the package using npm and save it as a dependency.
$ npm install --save @pedro-rodalia/vuex-cache
Basic usage
The cache vuex plugin uses axios interceptors and adapters in order to implement a cache system, so it needs an axios instance for it to work. The axios instance is passed as the first argument to the plugin initialization function. If there is no second argument specifying custom settings, it will run using the default settings.
// Import cache package
import cache from '@pedro-rodalia/vuex-cache'
// Create an axios instance where the cache will be implemented
const axiosInstance = axios.create(axios.defaults)
// Initialize Vuex plugin using the created instance and default settings
const cachePlugin = cache(axiosInstance)
// Use the plugin within the store
export const store = new Vuex.Store({
plugins: [
cachePlugin,
...
],
modules: {
...
}
})
Default global settings
By default, the plugin is configured to cache only 'get'
requests for every request that uses the axios instance. It stores the response for 60
seconds and has the garbageCollector
set to false
so the store will not clean itself up after a response is outdated.
It will try to fallback
to cached responses on internal server errors (500) and return responses with a 304
status and a 'Not modified'
message for cached responses and 'Fallback result'
for fallback responses.
Documentation
Using custom global settings
An object specifying custom settings can be passed as a second argument. This settings will override the default settings.
// Declare a configuration object
const config = {
methods: ['get', 'post'],
endpoints: [{
endpoint: '/users',
methods: ['get', 'post'],
exact: true
}],
ttl: 120,
garbageCollector: false,
fallback: [400, 500],
cachedResponseStatus: 304,
cachedResponseMessage: 'This is a cached response',
fallbackResponseStatus: 304,
fallbackResponseMessage: 'This is a fallback response'
}
// Initialize Vuex plugin using the created instance and custom settings
const cachePlugin = cache(axiosInstance, config)
Global settings
The custom configuration object can have the following properties.
Name | Type | Default | Description |
---|---|---|---|
methods |
array |
['get'] |
Defines a list of methods for which the responses will be cached |
endpoints |
array/object |
[] |
Defines a list of endpoints for which the responses will be cached / Defines an object with key/value pairs defining both the endpoint and the methods for the requests that will be cached |
ttl |
number |
60 |
Determines for how long a cached response is considered valid |
garbageCollector |
boolean |
false |
If set to true responses will clean themselves up after they are no longer valid responses (ttl seconds have passed) |
fallback |
array |
[500] |
Determines whether to answer a request with an outdated cached response if the request has returned an error. By default it only has this behaviour for INTERNAL SERVER ERROR (500) errors. |
cachedResponseStatus |
number |
304 |
Determines the http status code for the cached response |
cachedResponseMessage |
string |
'Not Modified' |
Determines the status message for the cached response |
fallbackResponseStatus |
number |
cachedResponseStatus |
Determines the http status code for the outdated cached responses used with the fallback feature |
fallbackResponseMessage |
string |
'Fallback result' |
Determines the status message for the outdated cached responses used with the fallback feature |
-
methods
andendpoints
By default the plugin will cache only get requests and only if the endpoints
property is not set. If we set the endpoints
property for caching a specific method/endpoint request, and we still want to cache all the 'get' requests for the other endpoints, the methods
property must be set manually and passed as a custom configuration.
// This configuration will cache all 'get' requests (default config)
const config = {}
// This configuration will cache all 'get' and 'post' requests
const config = {
methods: ['get', 'post']
}
// This configuration will ONLY cache 'get' requests for the users endpoint
const config = {
endpoints: [{
endpoint: '/users',
methods: ['get']
}]
}
// This configuration will cache 'get' requests for the users endpoint and 'get' and 'post'
// requests for any other endpoint
const config = {
methods: ['get', 'post'], // Set manually as custom config
endpoints: [{
endpoint: '/users',
methods: ['get']
}]
}
When the endpoints
setting is set the plugin will cache the responses from endpoints that match the endpoint property of each object within the setting. If we want to catch endpoints that exactly match this property, the match property must be set to true.
For example, if the /users
endpoint returns a list of users and the /users/:id
endpoint returns details about a specific user, we can cache just the list service which returns basic data unlikely to change, but still ask the server for the details.
// This configuration will cache get requests for the /users endpoint and
// the /users/:id endpoints
const config = {
endpoitns: [{
endpoint: '/users',
methods: ['get']
}]
}
// This configuration will ONLY cache get requests for the /users endpoint and
// not for the specific /users/:id endpoints
const config = {
endpoitns: [{
endpoint: '/users',
methods: ['get'],
exact: true
}]
}
-
ttl
The ttl
property specifies for how long a cached response is considered as valid. This means that if we make a request to an already cached endpoint, and ttl
seconds haven't passed, the response will be the cached response from the previous request. On the other hand, if ttl
seconds have passed, the response is considered outdated and the request is then resolved by the server.
If the garbageCollector
property is set to false
, outdated cached responses will be used as a valid response if the server returns any error included in the fallback
configuration array.
const config = {
ttl: 120 // Manually set the ttl to 2 minutes
}
-
garbageCollector
The garbageCollector
property configures timers for the cached response to clean themselves up. Once their ttl
has expired, the pair key/value for the response is deleted from the cache store. When garbageCollector
is set to true the plugin won't test cached responses expiration date, but the ttl
is still needed in order to configure the timers. If not set manually, responses will disappear after 60 seconds.
const config = {
ttl: 120, // seconds
garbageCollector: true // Responses will be deleted after 2 minutes
}
-
fallback
The fallback
property is used to determine a list of http status codes for which the response will try to return a cached response for that endpoint if it has been stored previously. If the garbageCollector
is set to true this feature will not work, because outdated responses are deleted and the only way to ask the service for a new response before the cached one has been deleted would be forcing the request using the reload
request configuration. When forcing the reload it doesn't make much sense to return cached data, which could lead to confusion.
By default, internal server errors (500) will try to fallback to cached data.
// Use the fallback feature for internal server (500) errors and not found (404) errors
const config = {
fallback: [500, 404]
}
// disable the fallback feature
const config = {
fallback: []
}
-
cachedResponseStatus
andcachedResponseMessage
This properties define the status code and status message for cached responses. By default is set to return a response with the 304
status code and a 'Not modified'
message, but can be configured to any other values.
// Use this configuration to make the cache system transparent
const config = {
cachedResponseStatus: 200,
cachedResponseMessage: 'OK'
}
-
fallbackResponseStatus
andfallbackResponseMessage
This properties define the status code and status message for responses used by the fallback
feature. By default is set to return a response with the cachedResponseStatus
code and a 'Fallback result'
message, but can be configured to any other values.
// Use this configuration to make the cache system transparent
const config = {
fallbackResponseStatus: 200,
fallbackResponseMessage: 'OK'
}
Using custom request settings
Most of the global properties can be set within the request configuration object and would provide the same functionality for that specific request.
Name | Type | Default (from global) | Description |
---|---|---|---|
ttl |
number |
ttl |
Determines for how long a cached response is considered valid |
garbageCollector |
boolean |
garbageCollector |
If set to true responses will clean themselves up after they are no longer valid responses (ttl seconds have passed) |
fallback |
array |
fallback |
Determines whether to answer a request with an outdated cached response if the request has returned an error. By default it only has this behaviour for INTERNAL SERVER ERROR (500) errors. |
cachedResponseStatus |
number |
cachedResponseStatus |
Determines the http status code for the cached response |
cachedResponseMessage |
string |
cachedResponseMessage |
Determines the status message for the cached response |
fallbackResponseStatus |
number |
cachedResponseStatus |
Determines the http status code for the outdated cached responses used with the fallback feature |
fallbackResponseMessage |
string |
fallbackResponseStatus |
Determines the status message for the outdated cached responses used with the fallback feature |
There are two more configuration options for specific requests which help manage the cache status.
groups
)
Creating groups (Requests can be grouped under a unique identifier using the group
property. This will save a reference to the cachedResponses that belong to the same group, so they can be deleted easily when needed.
This is useful because sometimes we want a specific request that modifies data in the server to clear any related cached response which would contain outdated data.
In order to achieve this we would group all the related requests under the same group. Requests can belong to multiple teams at once.
// Request configuration
const requestConfiguration = { groups: ['users'] }
// Use this configuration within multiple requests
api.get('/users', requestConfiguration).then()
api.get('/users/:id', requestConfiguration).then()
clear
)
Clearing groups (If we want to clear requests that belong to a specific group when we make a different request, the clear
setting must specify a list of groups we want to be cleared.
For instance, if we ask the server for a list of users that we think might have changed (using the reload
setting), we probably want the cache to remove all the cached responses for the individual users. This way, when afterwards we ask for a specific user, we get fresh data from the server.
// Request configuration
const requestConfiguration = { reload: true, clear: ['users'] }
// Clear the 'users' group
api.get('/users', requestConfiguration).then()
// Get fresh data from the server
api.get('/users/:id').then()
The request that triggers this setting doesn't necessary need to belong to the groups it clears.