Documentation / @warp-drive/core / types/request / CacheOptions

Interface: CacheOptions

Defined in: core/src/types/request.ts:43

Use these options to adjust CacheHandler behavior for a request via RequestInfo.cacheOptions.

Properties

___(unique) Symbol(SkipCache)?

optional ___(unique) Symbol(SkipCache): boolean;

Defined in: core/src/types/request.ts:90

If true, the request will never be handled by the cache-manager and thus will never resolve from cache nor update the cache.

Generally this is only used for legacy request that manage resource cache updates in a non-standard way via the LegacyNetworkHandler.

---

backgroundReload?

optional backgroundReload: boolean;

Defined in: core/src/types/request.ts:61

If true, and a cached response is present and not expired, the request will be made in the background and the cached response will be returned.

---

key?

optional key: string;

Defined in: core/src/types/request.ts:49

A key that uniquely identifies this request. If not present, the url wil be used as the key for any GET request, while all other requests will not be cached.

---

reload?

optional reload: boolean;

Defined in: core/src/types/request.ts:55

If true, the request will be made even if a cached response is present and not expired.

---

types?

optional types: string[];

Defined in: core/src/types/request.ts:80

Useful for metadata around when to invalidate the cache. Typically used by strategies that invalidate requests by resource type when a new resource of that type has been created. See the CachePolicy implementation provided by @ember-data/request-utils for an example.

It is recommended to only use this for query/queryRecord requests where new records created later would affect the results, though using it for findRecord requests is also supported if desired where it may be useful when a create may affect the result of a sideloaded relationship.

Generally it is better to patch the cache directly for relationship updates than to invalidate findRecord requests for one.