Honoring Cache-Control Header

[neilchaudhuri]

I am brand new to the library and have a very basic question about caching strategy. I have seen the API options for triggering manual and automatic revalidation, but does swr honor the max-age and stale-while-revalidate values that may come back in the Cache-Control header of the response from the fetcher?

[lukebarton]

useSWR requires users to pass a fetcher function having the type signature (key: string) => Data | Promise<Data> to 'get' the data so therefore useSWR itself doesn't know anything about your cache headers, just the data and the key it belongs to.

useSWR will cache the data until new data comes back to replace it, with fetches being triggered by revalidation events such as revalidateOnMount, revalidateOnFocus, or manual mutate invalidations, for example.

When swr tries to revalidate/fetch the resource via your fetcher caused by one of those events, your fetcher could make a HTTP request and then it'll go through your browsers HTTP cache at that point.

Going back to your particular use case, you could roll your own solution in your fetcher implementation:

const handles = new Map<string, number>();
const fetcher = async (key: string) => {
  const response = await fetch(key);

  clearTimeout(handles.get(key));
  const cacheControl = parseCacheControlHeader(response.headers.get("cache-control"));
  if (cacheControl.maxAge > 0) {
    const handle = window.setTimeout(() => {
      mutate(key);
    }, cacheControl.maxAge * 1000);
    handles.set(key, handle);
  }

  return  response.json();
};

This'll cause any resources fetched with this particular fetcher to mutate after their max-age, causing them to be refetched. You'll probably want to think about this a little more before just copy-pasting this code though.

[neilchaudhuri]

Thank you for the detailed and thoughtful response.

your fetcher could make a HTTP request and then it'll go through your browsers HTTP cache at that point.

I am confused by this. Are you saying Cache-Control alters the behavior of useSwr otherwise triggered by the revalidation events?

Your code example is helpful. I am hoping to recreate the same behavior as standard SWR (load from cache before max-age, load from cache and revalidate between max-age and SWR, revalidate after SWR), and your example should help with that.

[lukebarton]

useSWR itself doesn't know anything about http, or have any kind of ttl per resource you put into it's cache. It just knows that it has to revalidate (re-fetch) things from your fetcher when certain things happen based on it's configuration (e.g. on page focus, on component mount, at a set interval, on mutation etc).

useSWR -> fetcher(key) -> ?

If your particular fetcher happens to make a HTTP request, that request will potentially be served by your the browsers HTTP cache, but your fetcher only passes data back to useSWR, so that's why I say useSWR doesn't know anything about cache-control, max-age etc.

[neilchaudhuri]

I think I am getting it now. The triggers simply activate useSwr to in turn activate the fetcher. useSWR only cares about the result. The implementations details of the fetcher regarding where it pulled the data from--from a remote server or from a cache or whatever--are not its concern.

And incidentally, this would explain why the documentation uses "revalidate" vs "refetch." Because one does not always imply the other as whether revalidation results in an actual refetch from the server is at the discretion of the fetcher.

[lukebarton]

revalidate actually is a 'refetch', but it's just using terminology from stale-while-revalidate. But yeah, swr has a pretty dumb cache, but smart revalidation triggers. Building a fetcher that leverages the browsers http cache is smart, but comes with some caveats. You might want to check out my other post.

[neilchaudhuri]

Right now the idea on my project is for the server to send the appropriate caching headers with the response for the client to simply honor one way or another. The fetcher implementation you provided in your other post (or something like it) in combination with useSWRs triggers should be a good combination to make this happen.

[sergiodxa]

I think since the browser will honor the cache control requests, you should be able to let SWR call your API as many times as it needs, and your browser should be replying immediately from its cache instead of requesting the server.