fetcher revalidation after actions

[ryanflorence]

Right now, if an action is called (<Form>, submit, fetcher.submit, <fetcher.Form>) all of the loader data for the currently rendered routes are revalidated.

However ... any fetchers that have called fetcher.load() do not revalidate and it takes a bit of React Fu to get it to.

I've had a hunch since the beginning the fetchers with loaded data should be able to revalidate with actions as well. I hadn't taken the time to really think through use cases though. But then Santi sent me a perfect use case:

I would design this page something like this:

function ParentRoute() {
  // initialize with data from the loader for SSR/prefetching
  let loaderData = useLoaderData();
  let fetcher = useFetcher();
  // but use fetcher data once it lands when pagination starts
  let data = fetcher.data || loaderData;
  return (
    <ListDetailContainer>
      <VirtualList
        onNext={(index) => fetcher.load(`/items?after={index}&num=50`)}
        onPrev={(index) => fetcher.load(`/items?before={index}&num=50`)}
      >
        {data.map(item => (
          <NavLink to={item.id}>
            {/* ... */}
            <StarButton item={item} />
          </NavLink>
        )}
      </VirtualList>
      <Outlet />
    </ListDetailContainer>
  )
}

function ChildRoute() {
  let item = useLoaderData();
  let fetcher = useFetcher();
  return (
    <div>
      <h1>{item.title}</h1>
      <img src={item.image} />
      <StarButton item={item} />
    </div>
  )
}

function StarButton({ item }) {
  let fetcher = useFetcher();
  return (
    <fetcher.Form method="post" action={`/item/${item.id}/star`}>
      <input type="hidden" name="intent" value="changeStar" />
      <button name="status" value={item.starred ? "remove" : "add"}>
        {item.starred ? "★" : "✩"}
      </button>
    </fetcher.Form>
  )
}

This is great, until you click the star button. In either place because only the child route data will revalidate.

To make this work today, you'd need to pass a callback in to the child component to trigger the reload of the fetcher:

function ParentRoute() {
  let loaderData = useLoaderData();
  let fetcher = useFetcher();
  let data = fetcher.data || loaderData;

  // have to add a bunch of state first so that we even know
  // what to load after the star mutation (since it's not a callback
  // of the virtual list)
  let [virtual, setVirtual] = useState(null);

  React.useEffect(() => {
    if (virtual) {
      fetcher.load(`/items?${virtual.direction}={virtual.index}&num=50`)
    }
  }, [index]);

  return (
    <ListDetailContainer>
      <VirtualList
        onNext={(index) => setVirtual({ index, dir: "after" }) }
        onPrev={(index) => setVirtual({ index, dir: "before"}) }
      >
        {data.map(item => (
          <NavLink to={item.id}>
            {/* ... *}
            <StarButton item={item} onUpdate={() => {
              // revalidate the fetcher
              fetcher.load(`/items?${direction}=${index}&num=50`)
            }} />
          </NavLink>
        )}
      </VirtualList>
      <Outlet />
    </ListDetailContainer>
  )
}

function StarButton({ item, onUpdate }) {
  let fetcher = useFetcher();

  // add an effect to call the callback when it's done
  React.useEffect(() => {
    if (fetcher.type === "done") {
      onUpdate();
    }
  }, [fetcher.type]);

  return (
    <fetcher.Form method="post" action={`/item/${item.id}/star`}>
      <input type="hidden" name="intent" value="changeStar" />
      <button name="status" value={item.starred ? "remove" : "add"}>
        {item.starred ? "★" : "✩"}
      </button>
    </fetcher.Form>
  )
}

Proposal

I think useFetcher should be able to participate in revalidation just like route loaders already do.

It could look like this:

let fetcher = useFetcher({ revalidate: true })

• By default it continues to not revalidate after actions
• You opt-in to revalidations with the argument
• The normal route shouldReload continues to determine if it should revalidate or not, this way it doesn't matter which loader is called. After all, the idea of shouldReload is really only known by the loader to know what it depends on.

The only change this app requires now is simply telling the fetcher to participate in revalidation:

 function ParentRoute() {
   let loaderData = useLoaderData();
-  let fetcher = useFetcher();
+  let fetcher = useFetcher({ revalidate: true });
   let data = fetcher.data || loaderData;
   return (
     <ListDetailContainer>
       <VirtualList
         onNext={(index) => fetcher.load(`/items?after={index}&num=50`}
         onPrev={(index) => fetcher.load(`/items?before={index}&num=50`}
       >
         {data.map(item => (
           <NavLink to={item.id}>
             {/* ... *}
             <StarButton item={item} />
           </NavLink>
         )}
       </VirtualList>
       <Outlet />
     </ListDetailContainer>
   )
 }

Whichever star you click will call an action, routes will revalidate and the infinite scrolling list useFetcher will be revalidated as well.

Implementation Notes

There will need to be new internal state inside of transition manager to remember the last arg passed to fetcher.load(). After an action, iterate through the current fetchers and call load on the ones that want to participate in revalidation.

I think we should probably do this over in React Router as we're about to ship all of these data APIs over there and then it'll come back to Remix when we implement the new router.

[ryanflorence]

FYI: we've implemented this in React Router's data APIs and it'll come to Remix when we bring over the new Router to Remix.

[jaschaio]

Can we follow anywhere the progress of when the new Router will land within Remix?

And btw. this seems like a duplicate of #1301

[paul-vd]

I'm also wondering if we can track this somewhere, I ran into this issue today.

[dmarkow]

Remix 1.10.0 now includes automatic revalidation of fetchers, but it's turned on for all fetchers and there doesn't seem to be a way to override it (Ryan's proposal above included a {revalidate: true} option but I don't think that made it in)?

In the same way we can use shouldRevalidate at the route level, it would be great to have this on fetchers that we know don't need to be reloaded.

[jahvi]

It would be great to have a way of opting out of this behaviour, I have some requests I know don't need any revalidation and the only workaround now (I think) is to use fetch directly or something similar.

Edit:
I guess another workaround is to play around with the return value of shouldRevalidate but that can get messy if the fetcher is deeply nested.

[dantrain]

I tried logging the arguments to shouldRevalidate but they are identical between the fetcher call I need to block and the normal useLoaderData call I need to go through, so I can't distinguish. I need the useFetcher({ revalidate: false }) option to be able to upgrade Remix.

[hyperborea]

Just to add to above, being able to distinguish between loader and fetcher calls in shouldRevalidate is useful for the opposite use case as well: only revalidate fetchers, but not loaders (e.g. for infinite loaders).

[AmirL]

I had to use axious to send data to the api without refetching my current page :(. That is sad that api doesn't allow to update data which doesn't require to revalidate at least current page.

[coma]

I'm not sure if there is an issue related to this in my current project where we have a fetcher.Form to send an email (ajax is just fine for this one and we don't need to refresh the page) and after the post to the action there are some attempts to call all the loaders for this nested route but all of them are being cancelled (they reach the server anyway):

[KingSora]

@coma I have the same problem.. were you able to solve it somehow?

[coma]

No, I haven't found a solution for this so I had to move to another thing.

[kumarjatin19]

were you able to solve it now?

[KingSora]

@jk-innobit I know why it failed on my end.. I've unmounted the component which was calling the action before the state was back to idle. When that happens you cancel the subsequent loading process of the loaders. You can imagine it like:

1. The state is idle.
2. You send the action and thus the state switches to submitting.
3. After the action was completed the state switches to loading (to revalidate all loaders because of the action).
4. After the revalidation is done the state switches back to idle.

In my case I only checked whether the action returned some data without checking the state (which was loading at this point) is idleand unmounted the component which caused the revalidation to abort.

[hyperborea]

Even if revalidate would be implemented selectively on useFetcher, wouldn't the original use case (updating infinite loader after an action) still not work correctly? Only the latest fetch is being reloaded (2nd page in the example), but if the user performs an action on an item of the 1st page, that wouldn't be covered by the default revalidation.

I'm not sure how infinite loaders with actions should be implemented. Currently I'm submitting actions using vanilla fetch() not to trigger any revalidation and handle data refreshes and caching myself, but that becomes very complex very quickly. Apollo-client would fix caching and updates for me, but that's a pretty large migration away from using remix loaders.

[rajeshbabu-oviva-ag]

Precisely ended up with this problem today. May be we need to skip revalidation and use the response from Action as the source of truth.

[jianhuatu]

我认为非常需要useFetcher({ revalidate: true })，因为有的请求在action后不需要重新请求，有些时候是需要的。有一个配置来解决这个需求就太好了。

[fabregas4]

Strange to me that this is the default behaviour, at least how I intend to use fetchers.

Solved by putting shouldRevalidate = false on the fetcher route, but this wouldn't be possible if using the UI route as also the fetcher route, because as @dantrain said, there seems to be no way to distinguish between the default loader and fetcher loader when using the shouldRevalidate args.

Agree with others that useFetcher should have a revalidate option. I would say default to off, but either way need the ability to specify this.