Cancelation

[shuding]

⚠️ This proposal isn't finalized yet.

An abort signal will always be passed to fetcher via the option:

useSWR('/api', (url, { signal }) => {
  return fetch(url, { signal }).then(res => res.json())
})

And SWR will abort the signal when the request is discarded and the result is no longer needed. After aborted, SWR ignores the AbortError thrown.

[700software]

This is amazing! Elegant and in spirit with SWR's simplicity.

It would cause aborts to happen in applications where none were happening before. But is it a breaking change? I think not.

Edit: The PR for this actually is done but not merged:

• Issue 1933 - Cancellation of requests when no longer needed #2275

[l-mbert]

Looks good!
Maybe add a new configurarion option for People who don't want it?

[Viscount-Serpentis]

I have given implementation of this a go in the above PR if anyone is competent to have a look and give any feedback? Cheers.

[700software]

link to PR:

• Issue 1933 - Cancellation of requests when no longer needed #2275

[kirill-konshin]

Looks good. Close to the spec.

[700software]

this was originally posted in reply to #2312 (comment)

[jacobcoro]

Whatever happened with this? I would really like this feature

[timrae]

This feature would be super useful! The proposal looks good to me, seems to just be waiting on a PR code review?

[anandthirumala]

Please bring this on ASAP. Looks good. Thanks

[adam-rocska]

Yea, it’d be lovely to cancel stuff. Sure, most use cases are blazing fast, and bothering with a controlled cancelation wouldn’t make a product better, but there are some where it’s handy.

As I’m writing, we have a product engagement where by design the GUI app performs in parallel multiple lengthy API processes. At least tens of them, and each can vary between 10 and 50 seconds! In such cases it’s more than welcome to offer a “nah, I changed my mind, cancel dis job plz” feature to the user.

[Sreejit7]

Is there any update on this? It would be lovely to have the ability to cancel requests. We need it for a use case where if the user clicks back during an ongoing request, we wanna cancel it.

[jacobcoro]

Our current solution but it is pretty ugly:

  const ref = useRef<any>();

    const { data, isLoading, mutate, isValidating, error } = useSWR(
        'search',
        async (path) => {
            try {
                if (ref.current) {
                    ref.current.abort(); // This will abort the last api call when you want to make a new one to replace it.
                }

                const controller = new AbortController();
                const signal = controller.signal;
                ref.current = controller;

                const results = await  fetch(...)

                return { results };
            } catch (error: any) {
                if (!error?.message?.includes('abort')) {
                    return; // don't care about this
                }
                throw error;
            } 

[ckim16]

what would be the point of signal in this code?

[jacobcoro]

you have to pass signal into the fetch options to be able to abort it

fetch('your-url-here', { signal: controller.signal })

[iseki0]

Are there any concurrency? I means, will there any concurrent requests? The code doesn't allow it.

[UsamaEjaz0]

Any updates on this?

[sergnio]

Any updates?

I'm working on a project which uses SWR, and I've been enjoying it, though I would be lying if I said I don't miss React Query from time to time.

For anyone who isn't forced to useSWR in their project and is looking for a solution, take a peek over here in case RQ fits your project's needs better 👀
https://tanstack.com/query/v3/docs/framework/react/guides/query-cancellation#manual-cancellation

[joshkel]

Until this proposal is finalized (and/or #2275 is merged), we're currently experimenting with the following middleware to take a similar approach:

#2330 (reply in thread)