Expose fetcher.cancel() API

[nicholaschiang]

While it's currently possible to cancel in-flight useFetcher() requests by unmounting the React component that's performing them, it'd be nice to be able to programmatically cancel those requests within the component itself:

import { useFetcher } from 'remix';

export default function SomeComponent() {
  const fetcher = useFetcher();
  return (
    <div>
      <button type='button' onClick={() => fetcher.submit(null, { action: '/do-something' })}>Do Something</button>
      <button type='button' onClick={() => fetcher.cancel()}>Cancel Something</button>
    </div>
  );
}

[ryanflorence]

Can you list a couple use cases?

I'm unsure why you'd need to manually cancel a fetcher. Remix already handles interruptions, race conditions on revalidations, and unmounting. In the unmounting case, it's expected that if the fetcher is no longer needed, the component rendering it isn't needed either.

What product use cases are there that you would cancel a fetcher outside of interruptions and unmounting?

[nicholaschiang]

I discussed my use case in the Discord server earlier:

Fixed the race condition issue by simply unmounting the component that's sending the sync api request after a logout (e.g. conditionally rendering it only when someone is logged in). There is still a slight race condition between when the root loader is reloaded (and the new undefined user data is loaded) and the sync api request resolving (e.g. if the sync api resolves in the slight window after the /logout action has resolved but the new root loader has yet to be reloaded, the user will be seen as logged in incorrectly).

Being able to manually cancel the fetcher would address those very edge-case cookie session management issues.

[moishinetzer]

I just came into a use-case when users want to cancel a file upload.

[jason-weise]

Agree with @moishinetzer , we have the same use-case currently where we need to cancel file uploads

[dperetti]

My use case is the content of a tooltip, right now.

[duailibe]

Btw with v3_fetcherPersist they aren't removed after unmount, so there's effectively no way to cancel them

[rbrcurtis]

Another example:
Reference the "advanced page" infinite scroll remix example and make the server response a little slow. Then scroll across pages such that you get to page 3 before page 2 has loaded. Page 2 will get canceled by page 3 so the rows for page 2 never saturate. Here's a fork with a 3s delay on the server: https://codesandbox.io/s/thirsty-goldwasser-cd9mkg

If we had the ability to control fetcher cancellation this could be resolved. As it stands I would hesitate to use the advanced implementation.

[wub]

This would also be helpful for us.

In our scenario, we have a select input that, when changed, triggers an action. The action will either be a fetcher.load, or setting state from hardcoded values.

For example, the options might be:

1. Load options from /api/categories (fetcher.load)
2. Load options from /api/brands (fetcher.load)
3. Populate options from hardcoded list

If we load 1, then switch to 2, it works fine, because the second load cancels the first. However, if we switch from 1 or 2 to 3, the hardcoded results appear, but a second later, they're overridden by the fetcher.

We centralise "setting options" (we have 10+ options in the select, and they all share an interface). This means we can call setOptions(...opts) directly when needed.

useEffect(() => {
    setOptions(fetcher.data ?? []);
}, [fetcher.data]);

It would be nice to be able to cancel the fetcher without having to add another layer of "if this option is still selected then apply the fetcher data otherwise don't".

In the meantime, we'll probably refactor the component to use sub-components, each with their own fetcher (so it'll cancel on unmount).

[wub]

Just looping back to say that refactoring was the right move in our particular case, as it removes the need for an "imperative" cancellation, and means that we're now using fetcher in the intended manner.

[topaxi]

Came here because of need of cancellation, we have an upload dialog where we'd like to be able to explicitly cancel long running uploads. We do not want to unmount the component which triggered the upload though.

[akamfoad]

You could utilize AbortSignal.timeout and AbortSignal.any and pass them to the Fetch request, this works very well in the SPA mode, but note sure if this is ideal

export const clientLoader = ({ request })=>{
  fetch("/resource", {
    signal: AbortSignal.any([request.signal, AbortSignal.timeout(5000)])
  })
}

[topaxi]

Not really, there's no way to pass options to the fetch request being made by the fetcher API.

The example you gave is using a plain fetch call in a loader, my use-case is to cancel an action in the client.