Prefetching + useSuspenseQuery, nextjs data caching and invalidation

[mfrachet]

I'm starting toying with query prefetching + useSuspenseQuery in a Nextjs app and I have to admit that my brain is having trouble trying to figure out where caching should be made and where it should be invalidated 😅 .

My main goal is to achieve very fast navigation between pages where the first load shows the suspense boundary fallback (loading.tsx) and subsequent nav (using next links) should feel instant thanks to data cached in the browser (in tanstack query). In order to do so, I'm prefetching as much as I can on the server, serialize the query client and send it back to the hydration boundray provided by tanstack query.

Now comes the cache invalidation 🤯 .

Let's say I have a table of users and one can be edited. After modifying their firstname, should I revalidate at the nextjs level (tag / path) and prefetchQuery will good enough to rehydrate the client with the updated data from the server OR should I invalidate at the client level (queryClient.invalidateQueries) OR should I do both? If both are valid, what are the usecases and which one would be the most appropriate for my goal (=== fast nav)?

I hope this question is not too dumb, and I'm very sorry if it is :(

Thanks a lot for the job achieved in this library, you awesome folks 🙏🏻

[kostas-pblworks]

@mfrachet it always depends on your use case (UI, UX, setup, etc) ofc but I'll attempt to give my 5c.

I don't have a valid answer for which is best but my experience with Next.js revalidate* has been a nightmare and that's why I switched to react-query. revalidatePath will only work for a certain page and even though the docs say that it will work on the next visit, it actually works at that time if you're on the path you're invalidating. Furthermore, you don't know when the revalidation went through if you need to show a message and the page will have to re-render losing any state you currently have on (e.g. an open modal). revalidateTag seems like its a different mechanism which works only with network requests (fetch) or with some sort of a cache persistent storage for direct DB queries.

Do not use Next.js revalidate* if you're using react-query to manage the Users table, which if I get correctly you're using useSuspenseQuery. On edit of a row, either update that useSuspenseQuery's local state immediately to have optimistic updates and revert back if the update operation fails, either trigger that useSuspenseQuery's invalidation which will take a moment before it shows the updated value in the table.

It seems to me that these sort of reactive UIs weren't really what the Next.js team had on mind when they were building those mechanisms.