How to tell if a query was cancelled?

[ghost]

Currently, I have code that looks a little something like

async function someCallback() => {
    const res = await refetch();
    if (res.data) {
        // do something
    }
}

However, if the query already contains data and is cancelled, the promise returned by refetch() will resolve and data will still be populated. So // do something will run, which is not what I want when a query is cancelled.

How can I detect if a query has been cancelled from refetch()'s return value?

[TkDodo]

query cancellation puts a query back to the state it was previously in. once data is populated, it won’t be removed (not even if an error occurs).

What’s your use case? Maybe there’s a different way to get there :)

[ghost]

What I'm missing, and was surprised to not find, was some value indicating the cause for the promise resolution: if isSuccess is true, one would assume it's because the request was succesfull. If isError is true, the same but for an error. However, seeing the way cancellation is treated (query put back in previous state) there's no telling why the promise resolved, which is important to know.

[TkDodo]

what I don't understand is what needs to happen in // do something. I think this all looks a bit imperative. If you invalidate (or refetch) a query and want to perform an additional action when and if the data changes, you can:

• use the onSuccess callback of that query. It will only be called when the query was indeed successful
• spawn a useEffect that has data from useQuery as a dependency. It will always execute when data changes, and only then (due to structural sharing from react-query).

[ghost]

I think this all looks a bit imperative.

Not a bit, a lot! It's a complex form, and many fields are related to each other, and require updating, triggering side effects, or fetching for more data depending on their values.

I too was thinking about onSuccess and useEffect solutions you mentioned, although I believe both require an extra render to run (at least useEffect does), and wanted to avoid it by dealing with any updates or changes to the state directly from the someCallback handler.

[ghost]

How about adding an isCancelled prop to the request data?

[TkDodo]

although I believe both require an extra render to run (at least useEffect does),

the onSuccess solution does not, useEffect does, but an extra render should not be a big problem :)

maybe, you will also know that you don't need to do anything if data is equal to the data from useQuery?

const { data, refetch } = useQuery()
async function someCallback() => {
    const res = await refetch();
    if (res.data !== data) {
        // do something
    }
}

due to react-query's structural sharing, this should work for cancelled queries, as well for queries that were not cancelled but where the response from the backend was the same.
Alternatively, maybe comparing the .dataUpdatedAt flag of those two would suffice, because I don't think that would change when a query is cancelled.