Refactor/#71 - 풀리팩토링

[Kyujenius]

관련 이슈

• Resolves : [ Refactor ] - 풀 리팩토링 (다들 수고하셨습니다~~!) #71

작업 사항

급하게 마무리하느라 놓친 부분들에 대해서 리팩토링을 진행했습니다..! 각자 자랑스러울만한 레포로 가져가야죠 :)

1. 네이밍 컨벤션

   1. api 폴더 내엔 js, ts 파일들만 존재하기에, artworkDetail 과 같이 Camel Case를 사용하기로 했습니다..! 따라서 다음과 같이 폴더 명을 통일했습니다.
   2. page 폴더 내에선 SEO 최적화를 고려한 라우팅 및 가독성을 위해서 artwork-detail과 같이 Kebab Case 를 사용하기로 했습니다..! 따라서 다음과 같이 폴더명을 통일했습니다.
   3. component 폴더 내에선 Copmonent의 특성을 반영한 Pascal Case를 사용하기로 했습니다..! 따라서 다음과 같이 폴더 명을 통일했습니다.

2. queryKey, mutationKey 전면 수정

   1. queryKey,mutationKey 를 constants 내에 정의하게 된 의의를 되살렸습니다. constants 를 통해서 최초에 목표하고자 했던 것은 각 쿼리 키를 정하고, 추후에 무효화하는 데에 있어서 이를 생각해야만 하는 스트레스를 받는 경우가 있는데, mutation 함수를 통해 성공 여부에 따라 어떤 키를 무효화 해야할지를 설계 당시에 이걸 미리 다 정할 수 있도록 개선헀습니다.

3. mutationSuccessKey 추가

   1. mutationKey 내에서 mutationKey와, queryKey의 목적을 헷갈려 하시는 거 같아서 successMutationKey를 따로 두어, mutation이 성공했을 시에, 어떤 쿼리 키를 무효화 해야할지 작성했습니다.
   2. 추가적으로 무효화가 잘못 진행중인 key들을 전면 수정했습니다. (mutation 이 성공했는데, 다시 또 의미없이 mutationKey를 무효화하고 있는 경우나, 엉뚱한 queryKey를 무효화 해서 불필요한 fetching이 발생하는 경우)

4. constants 를 통해 함수와 키를 묶어서 미사용중인 코드들 개선

   1. 기존의 mutationKey 와 queryKey로 정의하는 코드와 사용하는 코드를 분리했습니다. 그 이유는 (2)번 이유와 같습니다. 따라서 이를 유지하기 위해 미정의해둔 queryKey 나 mutationKey를 추가적으로 정의하고 이 안에 각각의 api 호출이나, key들을 정의했습니다.

5. 에러 발생시, 전역 에러 처리 헨들링 수정

   1. 기존의 코드에서는 ErrorBoundary가 전혀 사용되고 있지 않았습니다. 아래에서 단계를 통해 설명 드리겠습니다.
   2. API를 통한 요청 -> Mutation을 통한 성공 실패 여부에 따른 처리 -> Component내에 데이터 랜더링 과 같은 순서로 진행된다고 했을 때, Mutation 단이 아니라, API를 통한 요청 단계에서 Error를 throw 하고 있기 떄문입니다. 이를 전면 수정하여, ErrorBoundary에서 정의한 DefaultErrorFallbackUI에서 에러를 볼 수 있도록 합니다. 이 과정에서 handleError 라는 함수를 만들었습니다.

6. handleError 를 통한 에러 헨들링 세분화

   1. 기존엔 AxiosError를 분리해, console에 찍는 것이 다였습니다. 혹은 통일성 없이 일부 페이지에선, toast.error를 통해 에러 메시지를 띄우는 것이 전부였습니다. 그러나 handleError를 사용하여, 치명적인 에러가 발생했을 시(화면 대부분을 차지하는 데이터를 띄우지 못 했을 때..!) 선택적으로 handleError를 통해 error를 throw 해줍니다.

참고 사항

• 다들 고생 많으셨습니다!