Controlling the client cache of RSC requests

[rmarscher]

I see that the waku/minimal/client includes some caching - but I think it is created on each render or prefetch process and then deleted afterwards.

It might be useful to be able to cache an RSC response and do invalidation and automatic re-fetches. A lot of the same options for TanStack Query would apply (staleTime, gcTime, networkMode, etc).

This could be applied to pages, layouts - and nested elements?

I don't think TanStack Router has a way to add caching. (This article on preloading)[https://tanstack.com/router/latest/docs/framework/react/guide/preloading#how-long-does-preloaded-data-stay-in-memory] says:

If you need more control over preloading, caching and/or garbage collection of preloaded data, you should use an external caching library like TanStack Query.

I wonder if leveraging @tanstack/query-core in a waku client implementation is a good idea.

[dai-shi]

I can expose a primitive API from waku/minimal/client, and waku/router/client should provide the user facing API.
The implementation shouldn't be hard, but we should be able to learn APIs from TanStack.

Having that said:

Is it correct that your requirement is to cache "dynamic pages" or "dynamic elements"? Because, we never invalidate static pages/elements (which should return the same content anyway.)
Waku's philosophy is not to cache dynamic pages. And, caching should be provided as an opt-in feature.

This could be applied to pages, layouts - and nested elements?

That's tricky, right? What should the user-facing api look like in your mind?

Another concern of mine is that cache should be controlled from the server not from the client, as the server should have more knowledge about the data lifetime.

[rmarscher]

Here's a use case: A custom dashboard per user that is loading data via suspense that takes some time. If I navigate to a detail page and then navigate back to the dashboard, I don't want to immediately see the loading screens again while it refetches everything. I want to be able to see the cached page immediately and kick off a refetch in the background if it is past the stale time. I'd like parts of that page to automatically refresh if I leave it open. It would also be nice to be able to work offline. Using waku's router/client for offline caching might be better than a separate PWA service worker.

What should the user-facing api look like in your mind?

I think it would be options for createPages (mainly the CreatePage and CreateLayout types) and a special component that could be used to create a nested element boundary, which could define caching and refetch functionality in it's props. It's probably natural for that component to also be a Suspense boundary.

cache-control headers could potentially work although I would need to make sure to vary the cache for each user and it's harder to control and invalidate.

cache should be controlled from the server not from the client

Maybe server response headers should pass information to the client on how it can cache the content. The stale-while-revalidate cache-control header is similar - except that might conflict with other parts of the stack, so it's probably better to use a custom header.

I actually hadn't looked at what NextJS provides. They have a router cache and It looks like they just added a similar staleTimes option. 🤷

[dai-shi]

I think it would be options for createPages (mainly the CreatePage and CreateLayout types) and a special component that could be used to create a nested element boundary, which could define caching and refetch functionality in it's props. It's probably natural for that component to also be a Suspense boundary.

It's a significant change. We need to take time to figure it out.
I'd actually prefer an opt-in feature, provided separately. I'll think about it.

cache should be controlled from the server not from the client

While I said that, your use case is client issue. So, it seems different.
I think I should first learn more use cases before coming up with server-controlled cache.

[rmarscher]

Yes. It is not urgent. Maybe there is a combination of server and client cache control that could be useful in certain scenarios.

[dai-shi]

Using waku's router/client for offline caching might be better than a separate PWA service worker.

That makes more sense to me. Though, the problem is slightly different from cache control in general. It's stale-while-revalidate only.

I don't want to immediately see the loading screens again while it refetches everything.

I see. Good point. We could see if defaulting to s-w-r for navigating to back. Though, it feels tricky because s-w-r kills React Suspense.

[rmarscher]

Yeah, it is tricky... each Suspense boundary could have it's own cache / s-w-r, maybe? I think it might be possible to implement s-w-r in an example with the Waku minimal API to understand it better.

[dai-shi]

Let me try something for the navigation back use case.

[rmarscher]

Here are some more thoughts on how this could work.

[rmarscher]

Here is the source for the excalidraw if you want to use and edit it.
waku-client-cache.excalidraw.zip

[rmarscher]

I think there might be a way to have the best of both worlds, client cache and React Suspense, by using cached content as the suspense fallback if it is available.