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!