Add revalidatingUrl: URL argument to ShouldRevalidateFunctionArgs to better support generic revalidation logic (like opting into pre-single fetch behavior!)

[willhoney7]

Problem

With the update to single fetch, when navigating child routes, the parent is also revalidated by default.

For the following example navigation, /animals/dog to /animals/cat

	before	after single fetch
/animals loader	defaultShouldRevalidate: false	defaultShouldRevalidate: true
/animals/cat loader	defaultShouldRevalidate: true	defaultShouldRevalidate: true

This is a huge behavior shift which has reasons—that's fine, it's probably a good default for most apps. Our app is very data/server intensive and we intentionally followed this hierarchy to make navigations fast and efficient. The challenge we face, however, is that the old behavior is difficult to generically opt back into.

Consider the ShouldRevalidateFunctionArgs:
https://github.com/remix-run/react-router/blob/1518f7d5d58553859eb2bc3490609a47ded3060f/packages/react-router/lib/router/utils.ts#L168-L182

For a navigation, you can look at nextUrl and currentUrl. However, there's no argument indicating what the revalidatingUrl (or current route, the route where the shouldRevalidate function is defined) is. I cannot create a shared, generic shouldRevalidate function that all of my routes can import and re-export. To opt into the previous behavior, I have to pass in the route that is calling shouldRevalidate. Something like

// routes/animals.tsx
export const shouldRevalidate = createShouldRevalidate('/animals');

// routes/animals.dog.tsx
export const shouldRevalidate = createShouldRevalidate('/animals/dog');

// some util
function createShouldRevalidate(pathname: string) {
   return (args: ShouldRevalidateArgs) => {
      if (args.nextUrl.pathname.startsWith(pathname) && args.nextUrl.pathname !== pathname) {
         return false;
      }
      return args.defaultShouldRevalidate;
  }
}

This simple example is fine, but what happens when you're now nested many routes deep? What happens when there's path variables? Now it can't be a startsWith, it has to parse the variables to check for path matching. Also, what happens if I reorganize my routes? I would have to update every shouldRevalidate manually.

Proposed Solution

The bottom line is that we need an easy way to identify that a navigation request is a child route navigation and be able to say shouldRevalidate is false for this situation.

I think the best way to do this would be to add a revalidatingUrl: URL argument to ShouldRevalidateFunctionArgs. This would be the url of the current route file.

For the following example navigation, /animals/dog to /animals/cat, these are what the ShouldRevalidateFunctionArgs would look like for the two routes.

route	currentUrl	nextUrl	revalidatingUrl
/animals route	/animals/dog	/animals/cat	/animals
/animals/cat route	/animals/dog	/animals/cat	/animals/cat

This is a very generic and powerful solution. I think this would provide a lot of value for the future and provides flexibility for all sorts of generic shouldRevalidate use cases. I also hope this would be fairly easy to implement, although I have not looked at any of the code to know for sure.

Other things I considered

• Add a defaultShouldRevalidateLegacy boolean which mimics the pre single-fetch behavior. Yuck.
• Add a isChildRouteNavigation boolean... Yuck.
• Add my own server-side cache to cache the heavy resources and let the new loader revalidation behavior stand. It would work, but it's a lot of extra work where using shouldRevalidate is so close to being an elegant solution.

Conclusion

I've seen a few people in discord bring up this issue. I'm hoping this official proposal can get us working towards a solution!

[Klukies]

Hey 👋

I've posted the same discussion after migrating from Remix to React Router in that repo.
Posting it here so when an answer is provided, both of these can be resolved 😊.

[willhoney7]

thank you! I'm going to link my proposal to your discussion as well! Hopefully we can get a solution here.

[brettburley]

I think shared revalidation logic is really important in most large applications, so I agree with the intent of this proposal, and in need of a solution too!

In general the ergonomics of using URLs to understand the route structure seems unnatural given the routes.ts primitives with a very structured route tree. I long for the ability to use something like the matches structure that's returned in useMatches, however even with that there needs to be a way to annotate a particular match as the current route module, or as a separate argument to shouldRevalidate denoting the module's route id (similar to your proposal here). However, with the match structure, you could more easily validate the child-ness of a route without having to parse the URLs, e.g.:

export function shouldRevalidate({ revalidatingId, nextMatches, defaultShouldRevalidate }) {
  if (nextMatches.slice(0, -1).some(match => match.id === revalidatingId) {
    return false;
  }
  return defaultShouldRevalidate;
}

Also, I wish there was another mechanism to get the current route ID/path without passing the revalidatingUrl as a function arg, but can't think of any mechanism given that these are module-level functions without introducing some kind of vite or generated code dependency.

With that said, I think the proposal here makes a lot of sense given the current signature of shouldRevalidate.