Class CachePolicy
publicA basic CachePolicy that can be added to the Store service.
Determines staleness based on time since the request was last received from the API
using the date
header.
Invalidates any request for which cacheOptions.types
was provided when a createRecord
request for that type is successful.
For this to work, the createRecord
request must include the cacheOptions.types
array
with the types that should be invalidated, or its request should specify the identifiers
of the records that are being created via records
. Providing both is valid.
[!NOTE] only requests that had specified
cacheOptions.types
and occurred prior to the createRecord request will be invalidated. This means that a given request should always specify the types that would invalidate it to opt into this behavior. Abstracting this behavior via builders is recommended to ensure consistency.
This allows the Store's CacheHandler to determine if a request is expired and should be refetched upon next request.
The Fetch
handler provided by @ember-data/request/fetch
will automatically
add the date
header to responses if it is not present.
[!NOTE] Date headers do not have millisecond precision, so expiration times should generally be larger than 1000ms.
Usage:
import { CachePolicy } from '@ember-data/request-utils';
import DataStore from '@ember-data/store';
// ...
export class Store extends DataStore {
constructor(args) {
super(args);
this.lifetimes = new CachePolicy({ apiCacheSoftExpires: 30_000, apiCacheHardExpires: 60_000 });
}
}
didRequest (request, response, store, identifier) Void public
Defined in ../packages/request-utils/src/index.ts:784
- request
- ImmutableRequestInfo
- response
- ImmutableResponse
- store
- Store
- identifier
- StableDocumentIdentifier | null
- returns
- Void
Invoked when a request has been fulfilled from the configured request handlers. This is invoked by the CacheHandler for both foreground and background requests once the cache has been updated.
Note, this is invoked by the CacheHandler regardless of whether the request has a cache-key.
This method should not be invoked directly by consumers.
invalidateRequest (identifier, store) public
Defined in ../packages/request-utils/src/index.ts:734
- identifier
- StableDocumentIdentifier
- store
- Store
Invalidate a request by its identifier for a given store instance.
While the store argument may seem redundant, the CachePolicy is designed to be shared across multiple stores / forks of the store.
store.lifetimes.invalidateRequest(store, identifier);
invalidateRequestsForType (type, store) public
Defined in ../packages/request-utils/src/index.ts:754
- type
- String
- store
- Store
Invalidate all requests associated to a specific type for a given store instance.
While the store argument may seem redundant, the CachePolicy is designed to be shared across multiple stores / forks of the store.
This invalidation is done automatically when using this service for both the CacheHandler and the LegacyNetworkHandler.
store.lifetimes.invalidateRequestsForType(store, 'person');
isHardExpired (identifier, store) Boolean public
Defined in ../packages/request-utils/src/index.ts:839
- identifier
- StableDocumentIdentifier
- store
- Store
- returns
- Boolean
true if the request is considered hard expired
Invoked to determine if the request may be fulfilled from cache if possible.
Note, this is only invoked by the CacheHandler if the request has a cache-key.
If no cache entry is found or the entry is hard expired, the request will be fulfilled from the configured request handlers and the cache will be updated before returning the response.
isSoftExpired (identifier, store) Boolean public
Defined in ../packages/request-utils/src/index.ts:867
- identifier
- StableDocumentIdentifier
- store
- Store
- returns
- Boolean
true if the request is considered soft expired
Invoked if isHardExpired
is false to determine if the request
should be update behind the scenes if cache data is already available.
Note, this is only invoked by the CacheHandler if the request has a cache-key.
If true, the request will be fulfilled from cache while a backgrounded request is made to update the cache via the configured request handlers.