How to properly update the error type of a query/mutation result?

[Ionshard]

I am getting started with react-query and we have an Axios API library automatically generated from Swagger.

Additionally many many of our REST endpoints always return the same data structure on an error and we have our own internal error codes. To handle the myriad of errors that can possibly go wrong when making an API call, I have created a parseError utility function that takes an unknown error and will return a discriminated union that categorizes the error into many possible errors (one of which is our standard API error response). This utility function is extremely useful when combined with ts-pattern which allows us to write very clean and exhaustive error code.

Here is a sort of mock example of what this gives us where we can super easily match our standard API error for an INVALID_FILTER code and extract the detailedMessage from the data for use. Or we match a 403 response, otherwise we handle the unknown error.

const TaskInfo = ({id}: {id: number}) => {
  const { data, isLoading, isError, error } = useQuery({
    queryKey: ['getTask', id],
    queryFn: () => getTask(id)
  });

 if(isLoading) return <Loader />

 if(isError) return match(parseError(error))
    .with({type: 'ApiError, errorCode: INVALID_FILTER, detailedMessage: P.select()}, (message) => <InvalidFilterError message={message} />)
    .with({type: 'HttpError', code: 403}, () => <NotAuthorisedError />)
    .otherwise(() => <UnknownError />)

  return <TaskContent task={data} />
}

Now my problem. useQuery by default has an unknown error type. When creating our custom hooks that use react-query I would love to handle the automatic error parsing as part of it, since we are a growing team making sure everyone remembers to parse the error and handle all potential issues can be difficult and hopefully I can eventually just auto generate these hooks from the swagger as well.

However, I can not for the life of me figure out how to properly type a hook that updates the error type.

Essentially what I am looking at is how I could write a hook like this, but without Typescript errors.

const useGetTask = (id: number): UseQueryResult<Task, ErrorResult> => {
  const result = useQuery({
    queryKey: ['getTask', id],
    queryFn: () => getTask(id)
  });

  if(result.isError){
    result.error = parseError(result.error);
    return result;
  }

  return result;
}

Here is a reproduction. You can ignore the majority of the parseError implementation. Just know that it is a function that takes in an unknown error and returns an ErrorResult discriminated union. The issue is at the bottom of the reproduction in the useGetTask hook.

Any thoughts?

[TkDodo]

The issue is at the bottom of the reproduction in the useGetTask hook.

it looks like re-assigning result.error doesn't change the type of error. I think you would need a type assertion here:

  if(result.isError){
    result.error = parseError(result.error);
    return result as UseQueryResult<Task, ErrorResult>
  }

however, it still doesn't check out because you return result at the very end, and there, you haven't transformed the error. Is there a reason why you can't always call parseError and handle the null check inside of it? That would enable you to at least do:

  const result = useQuery({
    queryKey: ['getTask', id],
    queryFn: () => getTask(id)
  })

  result.error = parseError(result.error);
  return result as UseQueryResult<Task, ErrorResult>

[Ionshard]

I was thinking about doing it in the queryFn but my concern was what would happen if an error occurs in the select property? We're often dealing with poorly defined backend data so sometimes we will use Zod in the select to validate the data against a stricter schema.

EDIT: Oh ... I can just do the same pattern in the select function. I will give this a go! I didn't know about tracked queries ... but now that I do I definitely want them! 🤣

[TkDodo]

yeah it wouldn't cover errors from select. But parsing backend data is something that I would do in the queryFn. Otherwise, you'll cache the wrong response, you'll retrieve the wrong response with queryClient.getQueryData, and you'll need to transform with select for every subscriber.

[Ionshard]

That is valid, but we are explicitly doing it in the select because we want to avoid cache bashing other queries. So we cache the exact data that is returned from the back-end and individual uses can further narrow it down via select if they so desire without affecting any other queries. In the case of using Zod to "parse" ... no actual data transformation happens ... it's just letting Typescript know that the value adheres to a stricter schema at runtime (or we get a runtime error) but never modifies the data itself.

[TkDodo]

no actual data transformation happens

that's fine, it's just that zod, per default, strips away unknown fields and it can also do refinements on the actual values at runtime. But yes, you don't need to do that.

[Ionshard]

Awesome, I think I got this working with the try catch in the queryFn and in the select function. This turns out to be far better because it also solves the problem of parsing the error before it goes to onError in a useMutation when following the same pattern.

Thank you so much for the feedback!