Best way to access http status code?

[weyert]

I would like to be able to access status-code of the response. Now I am wondering what would be the best react-query approach to do this? I can imagine one way to do this is by writing a custom fetch-method which looks like the code snippet listed below. Is this right way to do it?

My end goal is to have a behaviour when it returns 401 it should try to get a new access token via the refresh token, if that fails too, it should redirect to the login page. I am currently thinking what the best way would be to handle this via react-query.

I am wondering how { data, code: response.status } could conflict with the built-in fuctionalities of the library, e.g. query cache

const fetchItem = (path: string, options: FetchItemOptions) => {
  const headers = {
    'Content-Type': 'application/json',
    Accept: 'application/json',
  };

  return fetch(`${PUBLIC_API_URL}/${path}`, {
    method: options.method,
    headers,
    body: options.body ? JSON.stringify(options.body) : undefined,
  }).then(async (response) => {
    const data = await response.json();
    if (response.ok) {
      return { data, code: response.status };
    } else {
      return Promise.reject({ data, code: response.status });
    }
  });
};

[viperfx]

Yep I had a very similar question and looks like you have a solution to get both the data and status! #572

Interested in what the best practices are.

[weyert]

Yeah, I am wondering the same. The data-property I am having is a bit painful when you a response from the request that also uses the same then you get: { data: { data: { } }, code: 200 }. The solution works but doesn't feel right yet

[E-Rosa]

This is the solution I came up with:

whislt handling the query, create a isAuthed state and set it depending on the status code. Then, return it using object deconstruction so that its consumption is similar to other native useQuery return values.

export function useCourseClasses(courseId: string){
  const [isAuthed, setIsAuthed] = useState(false);
  const query = useQuery({
    queryKey: "courseClasses",
    queryFn: async () =>{
      const data = await getCourseClasses(courseId);
      const parsedData = await data.json();
      if(parsedData.data) return parsedData.data
      return parsedData
    },
    onSuccess: (data) => {
      if(data.status == 401){setIsAuthed(false)}
      if(data.status != 401){setIsAuthed(true)}
    },
  });

  return {...query, data: query.data as CoursePartialClasses, isAuthed: isAuthed}
}

Whilst rendering, check for both isAuthed and isSuccess to render whatever you'd like to render for status code 401.

  if (!isAuthed && isSuccess) {
    return <UnauthorizedResource />;
  }

[TkDodo]

onSuccess is deprecated. You're just looking at derived state:

const { data } = useQuery(...)

const isAuthed = data.status !== 401

[kamranayub]

Another option is to throw a custom error you can attach metadata to, this is how we typically handle this pattern.

interface FetchItemOptions {
  method: string;
  body?: unknown;
}

class FetchError extends Error {
  constructor(public res: Response, message?: string) {
    super(message)
  }
}

const fetchItem = (path: string, options: FetchItemOptions) => {
  const headers = {
    'Content-Type': 'application/json',
    Accept: 'application/json',
  };

  return fetch(`${PUBLIC_API_URL}/${path}`, {
    method: options.method,
    headers,
    body: options.body ? JSON.stringify(options.body) : undefined,
  }).then(async (response) => {
    const data = await response.json();

    if (response.ok) {
      return data;
    } else {
      throw new FetchError(response)
    }
  });
};

function fetchItemQueryFn(_key: string, itemId: number) {
  return fetchItem('/items/' + itemId, { method: 'get' })
}

const MyComponent = () => {
  const { data } = useQuery(['item', 1], fetchItemQueryFn, { 
    onError(err: FetchError) {
      if (err.res.status === 401) {
        window.location.href = '/login'; 
      }
    }
  })
}

useQuery now supports a TError generic so you can pass FetchError as your custom error type for strongly-typed errors 👍

[weyert]

Great thank you!

[igor-q-bio]

IMO, using exception as a control flow mechanism is an anti-pattern. For many cases, some 4xx (especially, 404) status codes may be considered as NOT network/service level errors.

[burrayto]

@igor-q-bio What pattern do you recommend for handling 404s? I'm trying to solve this problem myself.

[Deivid182]

Bro thank you so much for this solution. I literally spent so much time looking for a way to catch http errors so i can display different alerts and this fits me like a glove.