Include currentReferrerUrl & nextReferrerUrl in shouldRevalidate function for resource routes

[dT-Nick]

Proposal

Maybe I'm approaching this completely wrong, but currently the shouldRevalidate function includes the args currentUrl & nextUrl. When using a fetcher to load data from a resource route, both of those values are just the resource route's URL itself and they don't change (kind of as expected...). It would be super useful to include some sort of reference to the currentUrl & nextUrl that the fetcher is being called from for query string purposes.

E.g.

• User is on index page with a fetcher.load('/resource').
• User submits form with get method to add ?query=true to end of index URL.
• fetcher.load is revalidated & shouldRevalidate on /routes/resource.tsx is run. (Currently this doesn't actually happen, potentially a bug? See useFetcher: fetcher.load doesn't revalidate when search params change #5090)

// /routes/resource.tsx

export const shouldRevalidate = ({ currentUrl, nextUrl, currentReferrerUrl, nextReferrerUrl }) => {
  console.log(currentUrl.toString()) // http://localhost:3000/resource
  console.log(nextUrl.toString()) // http://localhost:3000/resource
  console.log(currentReferrerUrl.toString()) // http://localhost:3000
  console.log(nextReferrerUrl.toString()) // http://localhost:3000/?query=true
  
  // custom logic...
  return true
}

Motivation

That way I can keep all revalidation logic for resource routes inside of the routes themselves, instead of having to programmatically add relevant search params to the fetcher.load URL and reject all revalidation in the resource routes shouldRevalidate function otherwise.

I have no idea whether this would even be possible, and I'm sure I'm probably missing some gotcha somewhere, but could be a cool feature for enhancing a resource route's functionality. Excuse the terminology I'm using, it's probably wrong - but hopefully you can understand the idea I'm putting across.

I know that currently the formAction (in shouldRevalidate) contains the actual current route, including the search params e.g. ?index&query=true, but there's no reference to what that was previously when the loader was last called/revalidated, so you can't compare the search params.

[brophdawg11]

I realized this as well when digging into #5090. I think it's just an oversight bug since the whole point of revalidation is "where's the user at now, what did they do?". This should reflect the navigation (and does so in the form* arguments). I think currentUrl/nextUrl should reflect the active navigation.

The only question this opens up is - does the fetcher loader need access to the fetcher url and it's params. Consider fetching some user data in your app layout using a fetcher:

function Layout() {
  let fetcher = useFetcher();
  let userId = useUserId();
  
  // Load some data lazily on initial load, and let it automatically revalidate
  // Assume this is a resource route at /api/users/:userId/stuff
  useEffect(() => fetcher.load(`/api/users/${userId}/stuff`), []);
}

Now elsewhere in your app, the user submits a form which ends up redirecting between two unrelated URLs (/page-a -> /page-b). The fetcher shouldRevalidate call would reflect /page-a (currentUrl) and /page-b (nextUrl) and the submission from the navigation. So then you don't actually have access to the fetcher route params.userId anymore inside the fetcher shouldRevalidate - and maybe that's totally fine? shouldRevalidate for the fetcher is answering "given this submission navigation, does this route which loads user stuff need to revalidate?". It shouldn't concern itself with which user - that's the loaders job.

[dT-Nick]

Yeah I think you're probably right about the fetcher url not really being needed (and definitely not for my use cases anyway). I'm guessing the idea of having a currentUrl and a nextUrl is to track changes and creating revalidation logic based off of those changes. If the fetcher url does change, it wouldn't go through shouldRevalidate anyway. It's just a little concerning removing it entirely just in case there is an edge case where you might want to compare the active location url with the fetcher url, like so:

const shouldRevalidate = ({ nextParams, currentReferrerParams }) => {
  if (nextParams.userId === currentReferrerParams.userId) {
    return true
  }
  return false
}

I can't think of a time I'd actually ever do something like that but you never know whether it could be useful or not for someone at some point in time. Perhaps currentUrl, nextUrl, currentParams, nextParams should be the active location and extra parameters for the fetchers url could be added, where they would be undefined or null if there isn't a fetcher being used as above.