Next JS 14 serving precached layout and page while offline

[jlow2397]

Hello! Thank you for providing a great framework for setting up a service worker!

I have gone through the precaching docs here but I would love some help in trying to leverage the precache into my current Next JS app for offline routing functionality

I noticed that the static js/css files for my dynamic layouts and pages are stored in the serwist-precache-v2 cache (which is great!), but when I try navigating to a route that is not in the rscPrefetch or rsc cache while offline, my browser redirects to the chrome-error page

I understand that when routing the react server component is fetched first, and then the static js and css files are fetched in order to load the page, but is there any way to handle this process of serving the static js and css files directly from the precache to perform an offline navigation?

Any help is greatly appreciated, and I would be more than happy to share my learnings with others as this seems to be a common use case of using serwist with Next JS. Thank you!

[DuCanhGH]

@jlow2397

I understand that when routing the react server component is fetched first, and then the static js and css files are fetched in order to load the page, but is there any way to handle this process of serving the static js and css files directly from the precache to perform an offline navigation?

That your JS/CSS files are directly served from the precache doesn't change at any time. It's actually your pages not being cached that causes this issue.

To fix this, you have to cache your pages before they are visited. This can be done via window.serwist.messageSW({ type: "CACHE_URLS", urlsToCache: ["/a", "/b"] }). If you don't use Serwist's service worker API, you may need to process this message yourself, though.

Caching RSC responses may be a different story, though, as I haven't heard of a standard way to access the pages' RSC content. For example, in Next.js, statically generated pages have their RSC content dumped into .txt files, but dynamically generated ones have theirs only accessible via setting some sort of internal headers or search params.

You may also precache your pages, but that isn't recommended if they are dynamically generated as doing that causes them to always be served from the precache until the service worker is updated to not do so.

[DuCanhGH]

@jlow2397

will that affect the performance?

It is not really about performance, but rather about how the page would have incorrect data if you accessed searchParams on the server. Use useSearchParams instead.

I noticed that the network fetch is unique every time the id search parameter changes (which causes the load to fail when offline) so that might be what you are describing?

Use Strategy#options.matchOptions like so:

import { NetworkFirst, Serwist } from "serwist";

const serwist = new Serwist({
  runtimeCaching: [
    {
      matcher: ({ request }) => request.url.pathname === "/thread",
      handler: new NetworkFirst({
        matchOptions: {
          ignoreSearch: true,
          ignoreVary: true,
        },
      }),
    },
    ...defaultCache,
  ],
});

Or, if you precache the page, use precacheOptions.ignoreURLParametersMatching.

[jlow2397]

thank you adding a matcher for the request works great to cache the url

when rendering the cached page while offline however, it throws an error and shows the RSC router tree directly on the page like this:

0:["7_kj_6nxOoDMXvGYiStPS",[["children",["workspace","hq","d"],"children","mail","children","thread",["thread",{"children":["__PAGE__?{\"id\":\"18f9e4f34317c53a\"}",{}]},"$undefined","$undefined",true],null,null]]]

is this also related to an incorrect cache? in the network tab it loads the initial page from the service worker with a 200 response

[jlow2397]

I recently tried another approach with just a single url /thread and the id passed via a context state variable, but when navigating to the /thread page while offline it's triggering a full page reload (where it re-renders all the shared components in the layout)

is there a setting or caching strategy that is causing that behavior?

[jlow2397]

just a quick update: I ended up using next.prefetch('/thread') and it seems to have resolved the issue instead of using serwist.messageSW

thank you for all your help btw it's been great getting to learn a bit more about service workers through this package!

[DuCanhGH]

@jlow2397

next.prefetch('/thread')

😅

Alright, if that works in your favour.

I recently tried another approach with just a single url /thread and the id passed via a context state variable, but when navigating to the /thread page while offline it's triggering a full page reload (where it re-renders all the shared components in the layout)

Not too sure about this. Probably Next.js falling back to an actual browser navigation.

is this also related to an incorrect cache? in the network tab it loads the initial page from the service worker with a 200 response

Well, maybe. What I suggested was... well, a hypothesis, and I hadn't tried that before suggesting you to do so. In my opinion, caching some specific pages with themeId specified is the best option, but you do you :)