개요

tanstack-query 사내 도입 회고 1편 에서
사내 프로젝트에 tanstack-query를 도입하게 된 배경에 대한 내용을 작성했었다.

이번에는 눈에 보이지 않는 개선: My구독의 Redux에서 React-Query 전환 경험 공유 / if(kakao)2022
영상을 통해 kakao에서 tanstack-query를 도입한 방식과 develogger에 적용한 방식을 비교분석 해보려고 한다.

사내 프로젝트에 tanstack-query를 적용한 방식을 develogger에도 똑같이 적용해두었으므로
모두 develogger를 기준으로 설명하겠다. (회사 코드를 오픈 할 수는 없으니...)

react-query 도입 경험과 장단점에 대한 내용은 영상에 포함되어있으니 참고 바란다.

1. 구조 잡기(kakao)

kakao에서 총5가지 방법에 대해 고민하고 tanstack-query를 도입했다고 하는데 각 내용은 아래와 같다.

codegen을 도입하면

• Query 작성 방식
• QueryMutation 네이밍
• 폴더 구조
• QueryKey 작성 규칙

위 4가지 항목은 사실 저절로 해결된다.
(Swagger를 기준으로 모든게 규칙에 따라 만들어지고, 규칙이 잘 짜여있다)
kakao는 codegen을 사용하지 않으므로 직접 논의 후 컨벤션을 정해 작업한 것으로 보인다.

이 중 영상에 나오는 내용은 2가지 이다.

• Query 작성 방식
• 폴더 구조 개선

1-1. Query 작성 방식

영상 내용을 보면, 각 api별로 Query 훅을 작성하고 사용하였으나
이미 만들어진 Query가 재작성 되는 경우가 생겼던 듯 하다.
그 결과, api가 수정되면 관련 Query들을 모두 수정해야 되는 문제가 있었다고 한다.

그래서 기본 Query라는 이름으로 하나의 api와 1:1 대응되는 훅을 만들고,
컴포넌트에서는 기본 Query를 조합해서 사용하는 방식을 사용했다.

그러다보니 기본 Query에 공통 옵션을 주고 싶은 경우가 생겼고,
기본 Query를 한번더 래핑해서 사용하는 구조를 사용했다.
(영상에서는 기본Query를 위한 기본Query라고 설명)

1-2. 폴더 구조 개선

이는 redux + redux-saga를 사용했을때의 폴더구조 -> tanstack-query를 사용했을때의 폴더 구조 를 비교하는 내용이다. 기존에는 데이터의 목적으로 분류하였다면,
이제는 api 요청 형태에 따라 분류하게 되었다고 한다.

그리고 queries 내의 파일들은 데이터의 목적으로도 분리가 가능해서
각 컴포넌트 또는 훅에서 import시 import 경로에서부터 목적을 파악하기 좋았다고 한다.
또한 같은 Query는 공통화 되어있기 때문에 key가 달라서 api요청이 새로 나가는 케이스를 최소화 했다고 한다.

3편에서 계속...