TIL]2022/10/29

아침에 일어나 공부방에 갈 준비를 하며
오늘 하루를 짧게 계획했습니다.
스프린트를 할 때 조금 더 타이트하게 일처리를 했다면
금요일까지 에러 처리가 되었을 텐데..
스프린트를 할 때 조금 더 타이트하게 일처리를 했다면...
우선 로그인 에러 처리가 제일 우선이었고
공부방에 도착하면 로그인 에러 처리를 진행한 후
예약 내역 에러 처리를 진행해야겠다는 생각이 들었습니다.


공부방에 도착 후, 아침에 계획했던 대로 로그인 에러 처리를 진행했습니다.
처음 시도한 방법은 catch에서 throw new Error를 사용했는데
에러 처리에서 또 다른 에러를 유발하는 게 너무 어색하기도 하고
에러는 한 번만 처리하는 게 맞다는 생각이 들어
리덕스에 errorMessage 상태를 정의하고 errorMessage를
dispatch 해서 상태를 업데이트하는 방식을 채택했습니다.
그 후, 해당 요청을 하는 컴포넌트에서 useEffect를 통해
accessToken을 감지해 accessToken의 변화가 감지되면
예약 내역 페이지로 이동하고 errorMessage의 변화가 감지되면
alert을 띄우는 식으로 에러 처리를 진행했습니다.
예약 내역 페이지도 위와 같은 방식으로 에러처리를 진행하니
어느덧, 저녁시간이 되었습니다.


저녁을 먹은 후, 다른 팀원이 이메일 인증에 이슈가 있다고 하여
같이 분석을 하는 시간을 가졌습니다.
로컬 환경에서는 정상 작동했지만, 상용에서는 정상 작동하지 않는 이슈였고
문제를 해결하기 위해 백엔드 팀원과 프런트 팀원과 함께 원인을 찾기 시작했습니다.
어느 쪽에 문제가 있는지, 파악하기 힘들었고
처음부터 프런트 코드를 살펴보았어야 했는데...
몇 시간을 헤매다가 프런트 쪽 코드를 다시 살펴보았는데
useEffect에서 바로 api 요청을 하지 않고
return 즉, cleanUp 하는 부분에 api 요청 코드가 있어서
발생한 이슈였습니다.
로컬 환경에서는 React.StrictMode가 켜져 있어 두 번 렌더링 되기 때문에
cleanUp함수가 발동되었고 상용에서는 한 번 렌더링 되기 때문에
cleanUp함수가 발동되지 않았던 것이었습니다.
그 후, 문제가 되는 부분을 수정하고 배포를 하니 정상 작동하는 것을 확인했습니다.
처음부터 프런트 코드를 살펴보았어야 했는데...


오늘은 주말에 공부방에 나가서 평일보다는 여유 있게 공부를 했던 것 같습니다.
프로젝트를 진행하며 부족했던 부분들을 보완하면서 많이 배운 것 같습니다!