SWR library with ServiceWorker’s SWR caching strategy

[o-alexandrov]

Have you successfully implemented:

• this library with workbox‘s or any other library’s SWR caching strategy in a service worker?

I’ve used workbox StaleWhileRevalidate caching strategy with swr library, but stumbled upon an issue with useSwrInfinite:

• there is no rerender with updated data on revalidate for some reason

I will explore it more, but if anyone has successfully implemented it, it’d be great to hear your story

[sergiodxa]

I think except you want offline support there is no need to add a Service Worker to cache the requests, because now you have to deal with two caches instead of only one

[o-alexandrov]

For us, reasons to cache HTTP requests in a service worker are:

1. offline support
2. it's also a better UX to have two caches:
   • since a service worker w/ proper caching would let the page to load instantly, while loading updates
     • besides swr caching strategy, in service worker you can precache certain routes, same as with swr library, but before the app was opened

[o-alexandrov]

While it's totally understandable that swr library could possibly let the users to persist certain requests to LocalStorage, I think the limits of 2-10MB of LocalStorage & additional conditional complications of swr library don't sound reasonable.

[sergiodxa]

You can prefetch routes and let the browser cache them using a <link rel="preload" as="fetch" /> tag, I use it to preload the user data and SWR basically load instantly that request.

[o-alexandrov]

No, what you are referring to is different to what we try to solve.
For example, w/ your proposal you won't be able to:

• precache certain routes & requests when the app is installed on the user device, but hasn't been opened

preloading is same priority requests with the current ones. (parallel loading, while HTML is evaluated, in your case probably SSR rendered HTML)

• it is much worse UX, because the swr library doesn't necessarily have the data, when JavaScript is evaluated
  • especially on slower network, the link that is preloaded is not guaranteed to be available when JS is evaluated
    • whereas w/ a service worked you could control this

[o-alexandrov]

There other reasons why link preload would not be a universal solution for HTTP requests in an app, for example:

• it would be probably unreasonable to use it for cursor-based paginated requests

I agree, there are scenarios that are great for link preload, such as:

• static assets
• certain HTTP requests for installable apps that haven't been installed, like the requests you mentioned