Interface CacheProperties<R, D>

An object or function that will be tested against the response to indicate if it can be cached.

As most of our cache strategies depends on well known defined HTTP headers, most browsers also use those headers to define their own cache strategies and storages.

When your requested routes includes Cache-Control in their responses, you may end up with we and your browser caching the response, resulting in a double layer of cache.

This option solves this by including some predefined headers in the request, that should tell any client / adapter to not cache the response, thus only we will cache it.

These are headers used in our specific request, it won't affect any other request or response that the server may handle.*

Headers included:

• Cache-Control: no-cache
• Pragma: no-cache
• Expires: 0

Learn more at #437 and in this StackOverflow answer.

Asynchronously called when a network request is needed to resolve the data, but an older one and probably expired cache exists. Its with the current data BEFORE the network travel starts, so you can use it to temporarily update your UI with expired data before the network returns.

Hydrating your components with old data before the network resolves with the newer one is better than flickering your entire UI. This is even better when dealing with slower networks and persisted cache, like for mobile apps.

If the request can return cached data, as no extensive network travel is needed, the hydrate IS NOT CALLED, as the axios promise will be resolved instantly.

If activated, when the response is received, the ttl property will be inferred from the requests headers. As described in the MDN docs and HTML specification.

See the actual implementation of the interpretHeader method for more information.

Specifies which methods we should handle and cache. This is where you can enable caching to POST, PUT, DELETE and other methods, as the default is only GET.

We use methods in a per-request configuration setup because sometimes you have exceptions to the method rule.

Use If-Modified-Since header in this request. Use a date to force a custom static value or true to use the last cached timestamp.

If never cached before, the header is not set.

If interpretHeader is set and a Last-Modified header is sent to us, then value from that header is used, otherwise cache creation timestamp will be sent in If-Modified-Since.

This option bypasses the current cache and always make a new http request. This will not delete the current cache, it will just replace the cache when the response arrives.

Unlike as cache: false, this will not disable the cache, it will just ignore the pre-request cache checks before making the request. This way, all post-request options are still available and will work as expected.

Enables cache to be returned if the response comes with an error, either by invalid status code, network errors and etc. You can filter the type of error that should be stale by using a predicate function.

If the response is treated as error because of invalid status code (like when using statusCheck), and this ends up true, the cache will be preserved over the "invalid" request.

Types:

• number -> the max time (in seconds) that the cache can be reused.
• boolean -> false disables and true enables with infinite time if no value is present on stale-if-error in Cache-Control.
• function -> a predicate that can return number or boolean as described above.

The time until the cached value is expired in milliseconds.

If a function is used, it will receive the complete response and waits to return a TTL value

When using interpretHeader: true, this value will only be used if the interpreter can't determine their TTL value to override this