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:

react-router/packages/react-router/lib/router/utils.ts

Lines 168 to 182 in 1518f7d

	export interface ShouldRevalidateFunctionArgs {
	currentUrl: URL;
	currentParams: AgnosticDataRouteMatch["params"];
	nextUrl: URL;
	nextParams: AgnosticDataRouteMatch["params"];
	formMethod?: Submission["formMethod"];
	formAction?: Submission["formAction"];
	formEncType?: Submission["formEncType"];
	text?: Submission["text"];
	formData?: Submission["formData"];
	json?: Submission["json"];
	actionStatus?: number;
	actionResult?: any;
	defaultShouldRevalidate: boolean;
	}

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.

[gabro]

Adding my voice to this thread: I think for applications with lots of dynamic and user-specific data (e.g. apps behind a login) the previous behavior was a better default, since CDN caching was never an option anyways due to the nature of data.

While I appreciate the reasons that brought to this change in single fetch, I too think we need two things:

• the ability to recreate the previous behavior in userland shouldRevalidate
• the ability to set a default revalidation strategy (I currently have a globalShouldRevalidate that I manually apply to all routes, but that's tedious and error prone)

Thanks for considering it!

[eugeniobet]

Second this...

[brophdawg11]

In the example from OP - I agree that startsWith is not the right check. I think instead what you need to be passing in is the params for that route. That's really what makes a route know if it's being reused or not in non-mutation/non-search-params changing navigations.

The old behavior was to revalidate in 4 situations:

1. A mutation occurred
2. Identical href (ex. clicking a link to the same exact location which we treat as if the user clicked the refresh button, also applies to useRevalidator calls)
3. Search Params changed
4. A param for the current route changed so it's sort of a new "instance" of that route

1-3 are easily achieved with the current API, it's #4 that you need to be route-aware. Here's a simple implementation you would use for a given route that has a :slug dynamic param:

function shouldRevalidate({ currentUrl, nextUrl, currentParams, nextParams, formMethod }) {
  let isMutation = formMethod && formMethod !== "GET";
  let isPageReload =
    currentUrl.pathname + currentUrl.search ===
    nextUrl.pathname + nextUrl.search;
  let didSearchParamsChange = currentUrl.search !== nextUrl.search;
  // Note this needs to account for all dynamic params on this route's path if it has 
  // multiple, and also should account for any splat params
  let didMyParamsChange = currentParams.slug !== nextParams.slug;

  return (
    isMutation || isPageReload || didSearchParamsChange || didMyParamsChange
  );
}

To use your factory pattern above, what I would do is pass the params in and do something like this as your factory function

function getShouldRevalidate(params?: string[]) {
  return ({ currentUrl, nextUrl, currentParams, nextParams, formMethod }) => {
    // same logic for isMutation, isPageReload, didSearchParamsChange
    let didMyParamsChange = params ? 
      params.some(p => currentParams[p] !== nextParams[p]) : 
      false;

    return (
      isMutation || isPageReload || didSearchParamsChange || didMyParamsChange
    );
  }
}

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

// routes/animals.$animal.tsx
export const shouldRevalidate = createShouldRevalidate(['animal']);

You could even pretty easily extend that to account for search params that are relevant to the route to avoid unnecessary revalidations when meaningless search params change.

[brophdawg11]

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

This is true. I don't personally know if the ability to create a generic version is that much more helpful (also given the increased API surface of an API that's arguably already too large 🙃). You still have to go into every route and export const shouldRevalidate = myGenericShouldRevalidate. I don't think the DX is horribly worse if you are required to pass a params array to that type of approach. Yes, you need to change the code if you change the param name in routes.ts - but you also need to change the loader if you change routes.ts and anywhere else you access the params or useParams...

I also see the above request for the ability to set a default revalidation strategy - to me that sounds potentially more useful since it avoids the need to go add to every route - but I'm unsure if that's new API surface we want to adopt and if it would have downstream repercussions. We've also long noodled on call-site revalidation APIs which might also make that a moot point so I think we'd need to figure out what our thoughts are there before we considered adopting a new API for a global default if that proved to be a populare enough feature request.

[WillSmithTE]

Yes, you need to change the code if you change the param name in routes.ts - but you also need to change the loader if you change routes.ts and anywhere else you access the params or useParams...

Imo this is different because that's way easier to catch in unit or e2e tests, compared to shouldRevalidate