Advanced Error Handling in React Queries: Retrieving Server Error Codes Alongside isError Conditions

[ajaymahadeven]

I am exploring the possibility of enhancing error handling in React queries and would like to know if there's a method to not only determine if an error has occurred (as indicated by isError returning a boolean value) but also to retrieve the specific error code returned by the server. This additional detail would enable more precise logic based on both the status code and the isError condition.

For instance, in a scenario where I am working with a component that fetches data from a server, I would like to implement logic where the initial page is saved as a draft in case the server returns a 404 error (indicating the page ID was not found) combined with an isError type of undefined. Essentially, this would allow for different actions depending on whether the page exists or not when the component is rendered. Any guidance on methods or approaches to achieve this would be greatly appreciated.

[kapobajza]

This can easily be achieved by having a wrapper around the useQuery hook. Here's an example on how you can do it:

import { QueryKey, UseQueryOptions, useQuery } from '@tanstack/react-query';
import { useMemo } from 'react';

export const MyErrorCodes = {
  SomethingWentWrong: 10001,
  SomethingElseWentWrong: 10002,
} as const;

export class MyError extends Error {
  code: number;

  constructor(message: string, code: number) {
    super(message);
    this.code = code;
  }
}

export function useQueryWrapper<
  TQueryFnData = unknown,
  TError = Error,
  TData = TQueryFnData,
  TQueryKey extends QueryKey = QueryKey,
>(options: UseQueryOptions<TQueryFnData, TError, TData, TQueryKey>) {
  const useQueryResult = useQuery<TQueryFnData, TError, TData, TQueryKey>(options);

  const errorCode = useMemo(() => {
    // If queryFn throws an error of type MyError, you will be able to access the code property
    if (useQueryResult.error !== null && useQueryResult.error instanceof MyError) {
      return useQueryResult.error.code;
    }

    return undefined;
  }, [useQueryResult.error]);

  return {
    ...useQueryResult,
    errorCode,
  };
}

// Then you can use it like this:
const { errorCode } = useQueryWrapper({
  queryKey: ['myQuery'],
  queryFn: async () => {
    const res = await fetch('...');

    if (!res.ok) {
      throw new MyError('Something went wrong', MyErrorCodes.SomethingWentWrong);
    }

    return res.json();
  },
});

[ajaymahadeven]

While the above solution too is a good way to approach the requirement , but it's adding more code layers rather than streamlining the process.
Currently, the pattern involves writing a custom fetching function (fetchMyData) to manually check the response status and throw an error with the status code:

const { data, error, isError } = useQuery(['myData'], fetchMyData);
const fetchMyData = async () => {
  try {
    const response = await fetch('your-api-endpoint');
    if (!response.ok) {
      const errorCode = response.status;
      throw new Error(`An error occurred: ${errorCode}`);
    }
    return response.json();
  } catch (error) {
    throw error;
  }
};

While this works, it requires additional layers of code, and the error handling is less straightforward than it could be.

I propose an enhancement to the useQuery hook where it could directly provide the HTTP status code as an integer, similar to how isError returns a boolean. This feature would simplify error handling by reducing the need for custom fetch functions and manual error status extraction. It would enable developers to directly access the status code from the useQuery hook's return value, leading to more readable and maintainable code.

While this works, it requires additional layers of code, and the error handling is less straightforward than it could be.

I propose an enhancement to the useQuery hook where it could directly provide the HTTP status code as an integer, similar to how isError returns a boolean. This feature would simplify error handling by reducing the need for custom fetch functions and manual error status extraction. It would enable developers to directly access the status code from the useQuery hook's return value, leading to more readable and maintainable code.

const { data, error, isError, statusCode } = useQuery(['myData'], fetch('your-api-endpoint'));

Here, statusCode would directly provide the HTTP status code of the request, simplifying error handling and making the overall data fetching process more efficient.

I believe this enhancement would be beneficial for many developers who rely on React Query for data fetching and would appreciate your thoughts on this suggestion.

[kapobajza]

I think that the problem with your approach is that you're talking about HTTP requests, but TanStack Query isn't designed to be used only with HTTP or servers. It can be used for anything that returns a promise. What would be the value of statusCode if you're returning a Promise just to resolve some data that needs to be awaited on the client side? Like AsyncStorage from React Native? undefined? Well, that could really confuse a lot of people.

Or in the case of HTTP, what if someone uses fetch, whilst someone else uses axios, or some other library for fetching data? Getting the statusCode wouldn't be the same for every case, which could be hard to maintain for a feature that can be easily achieved by the average consumer.

[ajaymahadeven]

Your points are well-taken, highlighting the versatile nature of TanStack Query beyond just HTTP requests. It's true that accommodating a wide range of use cases, like Promise resolutions or varying fetching libraries, adds complexity to embedding HTTP status codes directly into the useQuery hook.

However, considering the common scenario of using TanStack Query with HTTP requests, perhaps a middle ground could be explored. What if, instead of modifying the useQuery hook itself, we introduce an optional, configurable wrapper or utility function specifically for HTTP requests? This utility could parse the HTTP status code and integrate it seamlessly with the standard useQuery return structure.

This approach maintains the generic utility of TanStack Query while providing an elegant solution for those of us dealing primarily with HTTP requests. It could look something like this:

const { data, error, isError, statusCode } = useHttpQuery(['myData'], fetch('your-api-endpoint'));

Here, useHttpQuery could be a custom hook that internally uses useQuery, handling the intricacies of HTTP status codes. This maintains the flexibility of TanStack Query for various scenarios while offering a streamlined way for HTTP-specific error handling.

[TkDodo]

you're better off using a wrapper around fetch (rather than a wrapper around useQuery) that handles this for you, like ky.