[2.0] React Query 공통 에러 핸들링

프로젝트에 리액트 쿼리를 도입하면서 이것저것 해보고 싶은게 많았다. 아래는 리액트 쿼리의 장점이라고 하면 자주 나오는 것들이다.

• 패치해온 데이터들을 캐싱
• stale한 데이터인지 아닌지를 구분해서 항상 신선한 데이터로 유지
• 서버 상태와 클라이언트 상태의 분리
• success와 error 등의 패칭 상태를 관리

특히 에러를 처리하는 방법에 있어서 고민을 더 해보고 싶었다. axios로 매번 패칭해올때 트라이 캐치로 감싸서 에러를 처리하는 코드를 자주 사용한다. 그럴 때마다 비슷한 로직(보통은 그냥 콘솔로그..)을 여기저기 작성하거나, 여러 페이지에서 공통으로 사용되어야 하는 로직도 중복으로 쓰이는 경우가 많았다. 전부터 고민을 몇번 했었던 부분이었는데 마침 참고할만한 좋은 레퍼런스들이 있어서 프로젝트에 넣어보고자 했다. 참고

 

백엔드 친구에게 이번엔 에러처리를 이러쿵저러쿵 해보고 싶다고 말했더니 이렇게 내려주었다. 모든 에러에 대해서 공통적으로 dto을 정의해주고, 스웨거까지 친절하게. 에러 코드마다 오는 형식을 한눈에 볼 수 있다. http 상태코드를 따르고 그에 맞게 에러메시지가 따라온다.

 

 

400 에러에는 다양한 이유가 있을 수 있다. BadRequest 에 대해선 "Auth-0002"와 같이 커스텀한 code를 같이 내려준다. ValidationError는 검증오류가 난 필드를 같이 내려준다. 똑같은 400이기 때문에 에러 코드만 보고 어떤 에러인지 판단하기 어렵다.

 

export interface ICustomError {
  error: string;
  statusCode: number;
  message: string;
  code: string;
}

export interface IValidationError extends ICustomError {
  validationErrorInfo: { [key: string]: string };
}

export type TCustomErrorResponse = {
  method: string;
  timestamp: number;
  statusCode: string;
  path: string;
  error: ICustomError;
};

에러 객체의 타입은 이렇게 정의했다. 에러가 발생하면 우선 React Query의 onError를 통해 에러 객체를 받는다. 그 이후에 에러 리스폰스를 뜯어보고 각각 에러마다 지정된 작업을 수행한다.

 

에러 처리 흐름을 일관적으로 잘 유지하기 위해서 관련 코드들을 분산시키지 않고 가급적 모아서 작성합니다. 특히 React를 이용하고 있으므로 Hook으로 에러 처리 흐름의 주요 로직을 작성합니다.

 

 

에러 처리 Hook

Query Client에 공통적으로 에러 핸들러를 사용하기 위해 리액트 훅을 사용한다.

 

const useApiError = () => {
  const { openErrorModal } = useErrorModal();

  const handleError = useCallback((axiosError: AxiosError) => {
    const errorResponse = axiosError.response?.data as TCustomErrorResponse;
    const error = errorResponse.error;
    const status = error.statusCode;

    switch (status) {
      // BadRequestException | ValidationError
      case 400:
        if (isValidationError(error)) {
          console.log(error.validationErrorInfo);
        } else {
          openErrorModal(error);
        }
        break;
      // 과도한 요청을 보낼 시
      case 429:
        openErrorModal(error);
        break;
      // 문자메시지 발송 실패
      case 500:
        defaultHandler(error);
        break;
      default:
        defaultHandler(error);
        break;
    }
  }, []);
  return { handleError } as const;
};

export default useApiError;

handleError 함수에선 에러 객체를 받아 코드별로 지정된 로직을 수행한다. 프로젝트에선 사용자가 봐야할 에러는 전부 모달을 통해 보여주고 있다. 400과 429에러가 이에 해당됨. (프론트앤드 단에서 한번 막고 요청을 보내기 때문에) 정상적인 경우라면 뜰 일도 없고 사용자에게 보여져서도 안되는 밸리데이션 에러는 그냥 콘솔에 띄우는거로 처리했다. 사실 타입가드를 여기서 한번 써보고 싶었음.

 

function isValidationError(error: any): error is IValidationError {
  return (error as IValidationError).validationErrorInfo !== undefined; // T of F
}

 

객체를 까서 내부 값을 보기 전에 타입 가드를 통해 error가 validationError 타입인지 확인하는 함수이다. if문으로 이리저리 확인해가면서 돌리는것보다 훨신 가독성있다.

 

export type TErrorCode =
  | 'Auth-0000'
  | 'Auth-0001'
  | 'Auth-9000'
  | 'Auth-5000'
  | 'Auth-0002';

const errorMessage = {
  'Auth-0000': '인증번호의 기한이 만료되었어요',
  'Auth-0001': '인증번호가 일치하지 않습니다',
  'Auth-9000': '잠시 뒤에 다시 시도해주세요',
  'Auth-5000': '문자 발송에 실패했어요\n카카오 채널로 문의주세요',
  'Auth-0002': '이미 가입된 번호입니다',
};

const useErrorModal = () => {
  const { openModal, closeModal } = useModal();

  const openErrorModal = (error: ICustomError) => {
    const code = error.code as TErrorCode;
    console.log(code);
    openModal({
      modalType: 'Notice',
      modalProps: {
        onClick: () => {
          closeModal();
        },
        type: '에러처리',
        errorMessage: errorMessage[code],
      },
    });
  };

  return { openErrorModal } as const;
};

export default useErrorModal;

useErrorModal에서는 커스텀 에러 객체를 받아 에러 코드에 맞는 모달을 띄우는 함수를 리턴한다. 에러용 모달은 같은 디자인에 문구만 다르게 들어간다.

 

 

 

리액트 쿼리 Default onError

QueryClient를 초기화 할때 모든 쿼리문에 디폴트로 적용되는 설정을 넣어 줄 수 있다.

const queryClient = new QueryClient({
  defaultOptions: {
    onError: handleError,
  },
})

간단히 이런 식으로 하면 됨.

 

하지만 내 경우엔 onError 이벤트에 커스텀훅에서 받아온 handleError 함수를 전달해야 했다. 그래서 index.tsx에서 App을 감싸고 있던 <QueryClientProvider/>를 App.tsx 내부로 가져와 감싸는 걸로 수정했다. 그랬더니 웬걸, 모달을 띄워야하는 상황마다 쿼리에 있던 캐시된 데이터들이 모조리 사라지는 일이 있었다. 응원톡 페이지에서 메시지들은 제대로 패칭이 되는데 쿼리 데브툴에는 안보이는 상황이었음. 적잖이 당황했다. 다행히 스택에 나랑 비슷한 경험이 있었던 사람이 자문자답했던 글이 있었다. queryClient가 App내에 있어서 재렌더링이 되는게 문제였다.

 

function App() {
  const { handleError } = useApiError();
  const queryClient = useQueryClient();

  queryClient.setDefaultOptions({
    queries: { onError: (error: any) => handleError(error) },
    mutations: {
      onError: (error: any) => {
        handleError(error);
      },
    },
  });

  // ...

우선 index.tsx에서는 아무런 옵션 없이 new QueryClient();로 쿼리클라이언트를 생성한다. 그 후 app.tsx에서 useQueryClient()로 인스턴스를 가져와 디폴트 옵션을 지정할 수 있다. onError 이벤트에 handleError를 전달해준다. 뜻하지 않은 삽질이었지만 나름 얻어가는게 많았다.