Revalidate The Data on Route change on react client for Next js

[naimulemon]

There are no existing feature requests related to revalidating data on route change in a React client for Next.js in the apollographql/apollo-client repository. I will now create a new issue for this feature request.

---

Feature Request: Revalidate Data on Route Change in React Client for Next.js

Description:
We would like to request a feature for revalidating data on route change in a React client when using Next.js. This feature would ensure that the data stays fresh and up-to-date as users navigate through different routes in a Next.js application.

Use Case:
When developing applications with Next.js and Apollo Client, it is essential to ensure that the data rendered on different pages is always up-to-date. Currently, developers need to manually handle data revalidation on route changes, which can be cumbersome and error-prone. Automating this process would greatly enhance the developer experience and ensure data consistency across the application.

Proposed Solution:
Implement a mechanism within Apollo Client that triggers data revalidation whenever a route change is detected in a Next.js application. This could be achieved by:

• Listening to Next.js route change events.
• Triggering a refetch of relevant queries when a route change occurs.
• Providing configuration options to customize the revalidation behavior (e.g., specifying which queries to refetch).

Benefits:

• Improved data consistency across different routes in a Next.js application.
• Reduced complexity for developers by automating the data revalidation process.
• Enhanced user experience with up-to-date data displayed on all pages.

Additional Context:
This feature would be particularly useful for applications that rely heavily on dynamic data and require real-time updates as users navigate through different pages.

---

I will now proceed to create this issue in the apollographql/apollo-client repository.

[phryneas]

Hi @naimulemon :)

Generally, Apollo Client doesn't include any tools that can only be used with only a single framework, with the exception of our @apollo/experimental-nextjs-app-support package, which is currently needed because React has no native way of supporting streaming SSR, so we have to rely on framework internals to make this work.

This feature request sounds like something that would need to be implemented in userland, but even there I see a few problems, since the Next.js App router does not have navigation events and there is no generally reliable way of telling which data will be consumed by a specific route unless you use fragment composition.

If you are using the App Router, my recommendation would be to use fragment composition in combination with preloading data in RSC for usage in Client Components, which will make sure that your data is always up-to-date on page navigation.

[therealgilles]

I think this could be implemented with an equivalent to TanStack Query invalidateQueries. The queries would be invalidated (manually) before the route change (assuming client-side navigation), then something like router.push() would be called and the rendering of the new page would automatically trigger the refetching of the queries necessary for rendering.

With invalidateQueries, the cache is marked as stale but still available, ensuring the refetch does not start until there is a re-render, so it won't start till after the route change.

A combination of Apollo Client and Tanstack Query may be a solution.

[jerelmiller]

A combination of Apollo Client and Tanstack Query may be a solution.

@therealgilles typically you would not be combining Tanstack Query and Apollo Client together since they are more-or-less "competing" libraries ("competing" meaning they both handle data fetching, so I'm not sure why you'd want to both to handle this). Using both also means 2 sources of truth for your GraphQL data which would probably get difficult to handle.

That said, what you're describing in terms of cache invalidation is very much an idea we'd like to pursue at some point. In fact I wrote down some thoughts in some replies to feature requests a couple weeks ago on this topic. That said, we're looking to make this more field-specific than query-specific. Check out the last half of this comment of mine if you're curious what we're thinking long-term.

[therealgilles]

@jerelmiller Thanks for the reply. I did see a number of the comments, some dated back to 2022 which makes me a bit nervous. On the topic of query vs field, I would think that query would be easier and most useful to common scenarios. I'm also surprised that the Apollo Client time does not have any notion of stale time.

I'm not sure why you'd want to both to handle this
Ideally not but as I explained above, trying to clear cache entries (on say, logout) before a route change without triggering a refetch (until after the route change) feels harder than it should be with Apollo Client when it's straight-forward with Tanstack Query.

(Addendum) I will most likely use Apollo Client on the server (which I guess means no real caching as it's going to be a new client for each request) to fetch from the backend, and then use Tanstack Query on the frontend to cache the data and avoid unnecessary refetches. I'm using NextJS with SSR.