Skip to main content
Version: 6.1

Expiry Policy

By default, Rest Hooks cache policy can be described as stale-while-revalidate. This means that when data is available it can avoid blocking the application by using the stale data. However, in the background it will still refresh the data if old enough.

To explain these concepts we'll be faking an endpoint that gives us the current time so it is easy to tell how stale it is.

lastUpdated.ts
class TimedEntity extends Entity {
pk() {
return this.id;
}
static schema = {
updatedAt: Date,
};
}
const fetchLastUpdated = ({ id }) =>
fetch(`/api/currentTime/${id}`).then(res => res.json());
const lastUpdated = new Endpoint(mockLastUpdated, { schema: TimedEntity });

Expiry status

Fresh

Data in this state is considered new enough that it doesn't need to fetch.

Stale

Data is still allowed to be shown, however Rest Hooks might attempt to revalidate by fetching again.

useResource() considers fetching on mount as well as when its parameters change. In these cases it will fetch if the data is considered stale.

Invalid

Data should not be shown. Any components needing this data will trigger fetch and suspense. If no components care about this data no action will be taken.

Expiry Time

Endpoint.dataExpiryTime

Endpoint.dataExpiryTime sets how long (in miliseconds) it takes for data to transition from 'fresh' to 'stale' status. Try setting it to a very low number like '50' to make it becomes stale almost instantly; or a very large number to stay around for a long time.

Toggling between 'first' and 'second' changes the parameters. If the data is still considered fresh you will continue to see the old time without any refresh.

Live Editor
Result
Loading...
Store

Endpoint.invalidIfStale

Endpoint.invalidIfStale eliminates the stale status, making data that expires immediately be considered 'invalid'.

This is demonstrated by the component suspending once its data goes stale. If the data is still within the expiry time it just continues to display it.

Live Editor
Result
Loading...
Store

Force refresh

Controller.fetch can be used to trigger a fetch while still showing the previous data. This can be done even with 'fresh' data.

Live Editor
Result
Loading...
Store

Invalidate (re-suspend)

Both endpoints and entities can be targetted to be invalidated.

A specific endpoint

In this example we can see invalidating the endpoint shows the loading fallback since the data is not allowed to be displayed.

Live Editor
Result
Loading...
Store

Any endpoint with an entity

Using Delete allows us to invalidate any endpoint that includes that relies on that entity in their response. If the endpoint uses the entity in an Array, it will simply be removed from that Array.

Live Editor
Result
Loading...
Store

Error policy

Endpoint.errorPolicy controls cache behavior upon a fetch rejection. It uses the rejection error to determine whether it should be treated as 'soft' or 'hard' error.

Soft

Soft errors will not invalidate a response if it is already available. However, if there is currently no data available, it will mark that endpoint as rejected, causing useResource() to throw an error. This can be caught with NetworkErrorBoundary

Hard

Hard errors always invalidate a response with the rejection - even when data has previously made available.

Live Editor
Result
Loading...
Store

Policy for Resources

Since 500s indicate a failure of the server, we want to use stale data if it exists. On the other hand, something like a 400 indicates 'user error', which means the error indicates something about application flow - like if a record is deleted, resulting in 400. Keeping the record around would be inaccurate.

Since this is the typical behavior for REST APIs, this is the default policy in @rest-hooks/rest

  /** Get the request options for this SimpleResource */
static getEndpointExtra(): EndpointExtraOptions | undefined {
return {
errorPolicy: error =>
error.status >= 500 ? ('soft' as const) : undefined,
};
}