Day 32 개발일지 Web

개발일지

Axios Interceptor Response설정

어제 Requset를 설정하였다면 오늘은 뭐다 ? Response다 👦
Response는 왜 하게 되었냐면.. 바로 Error처리 때문이다.
현재 컴포넌트내에 있는 에러처리의 대부분은 catch문으로 alert만 띄워주고 있고, 어떤 컴포넌트는 필요하지만 alert를 띄워주고 있지 않다.
또한 401에러를 받게되면 접근권한이 없기 때문에 로그아웃 되야 하지만 이게 잘 되지않고 있다.......
이를 해결하기 위해 Axios Interceptor Response에서 Error에 대한 경고문을 띄워주고, Local Storage 삭제와 Page Reload과정이 필요했다.
우선 401에러를 먼저 처리했다. => 401에러를 받는 녀석들은 앞서말한 local Stroage 삭제 및 page Reload 과정이 필요하다. 때문에 if문으로 필터하여 앞서말한 작업을 수행해줬다.
이 때 발생한 문제 🤦‍♂️
alert 경고창이 두번이나 뜨는 것이다. 또한 Modal의 경우 경고창을 띄우는 것이 아니라, 모달 안에 경고메세지를 보여주기로 하였기 때문에 alert창이 띄워지면 안된다.
내가 생각한 해결방법은 Modal창에 띄워지는 에러들은 3개가 정해져있기 때문에 400번(Client 문제) 코드중 의미가 없는 코드 하나를 가져와서 필터링 처리러 alert창을 띄워주지 않는 것 이었다 !!
그리고 403 에러의 경우 접근 차단된 것이기 때문에 별도의 Action이 필요해서 마찬가지로 Interceptor에서 alert를 띄우주면 안됐다.

const filterCode = [403, 488];
Axios.interceptors.response.use(
  (response) => response,
  (error) => {
    if (!filterCode.includes(error.response.status))
      alert(`${error.response?.data?.message || error.message}`);
    if (error.response.status === 401) {
      storageHandler.clear();
      window.location.reload();
    }
    return Promise.reject(error);
  },
);

이렇게 filterCode Array을 이용해서 Error Code를 필터해줬고, 401코드는 공통적으로 처리해야할 액션을 여기서 취해줬다.
Front-end를 하면서 '에러는 어떻게 일괄적으로 처리하는거지 ?' 라는 궁금증을 갖곤했는데 Interceptros 또한 하나의 방법이 될 수 있다는 것을 알게 되었다. 당연히 이방법말고도 다른 방법이 있을테니 꼭 다른 것도 찾아보자 !!

useTOTPModal 커스텀 훅

예전부터 생각했던 TOTPModal을 커스텀 훅으로 만드는 작업을 했다. 해당 모달은 로그인, 비밀번호 변경할 때 사용되는데 두 부분에서 중복되는 코드가 많아서 따로 훅으로 빼면 좋을 것 같았다.

보니까 otp를 제출하는 로직만 다르고 나머지는 동일했다. 그리고 qrcode 재발급 부분도 외부에서 authToken을 전달받아야 하기 때문에 따로 뺄 수 없었다.

결과적으로 qr재발급을 처리하는 reIssueHandler, otp 제출을 처리하는 submitHandler 2개를 입력으로 받고 필요한 모든 상태와 함수들을 리턴하는 훅을 만들 수 있었다.

  const {
    isModalOpen,
    openModal,
    closeModal,
    TOTP,
    setTOTP,
    hasTOTPModalError,
    modalDisabled,
    errorMsg,
    onReIssueQRCode,
    onSubmitOTP,
  } = useTOTPModal({ reIssueHandler, submitHandler });

설계 변경

우선 기존에 QR 생성 정보를 위한 Key 값을 그대로 넘기는 방법을 사용했으나 이에 문제는 Email 로 재전송 했을 때 만료시간에 영향을 받을 수 없다는 문제가 있었다 따라서 이를 해결하기 위해서 받는 값을 유저 정보로 바꾸고 다시 요청을 해서 Key 값을 넘기는 방식으로 변경하였다 이를 통해서 오히려 Key 값을 노출시키지 않는 방안으로 넘어가서 더 좋아진 느낌이다.

개인회고

진구

우선 에러코드부분은 이전 프로젝트들에서 엄청 가볍게 여기고 넘어갔던 부분이었다. 에러코드에 따른 액션을 따로 취해주지 않은것은 당연하였고, 에러메세지 조차 전달을 잘해주지 못했다.. 지난날에 신경쓰지 못하고 지나온 것이 조금 후회되지만.. 이제 하나를 알게된 만큼 다른 방법도 함께 찾아보고 나름의 정리를 하면 나중에 도움이 많이 될 것 같다는 생각이 들었다.

석암

설계 변경을 할일이 생겨서 설계를 변경하였다. 뭐 어려운건 없는데 항상 느끼는 것이 만드는 것보다 수정이 어렵다는 점이다.