Replies: 12 comments 6 replies
-
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: |
Beta Was this translation helpful? Give feedback.
-
Looks good! |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Looks good. Close to the spec. |
Beta Was this translation helpful? Give feedback.
-
Whatever happened with this? I would really like this feature |
Beta Was this translation helpful? Give feedback.
-
This feature would be super useful! The proposal looks good to me, seems to just be waiting on a PR code review? |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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;
} |
Beta Was this translation helpful? Give feedback.
-
Any updates on this? |
Beta Was this translation helpful? Give feedback.
-
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 👀 |
Beta Was this translation helpful? Give feedback.
-
Until this proposal is finalized (and/or #2275 is merged), we're currently experimenting with the following middleware to take a similar approach: |
Beta Was this translation helpful? Give feedback.
-
An abort signal will always be passed to
fetcher
via the option: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.Beta Was this translation helpful? Give feedback.
All reactions