React Query의 기술적 개념 및 사용 방법등은 다른 블로그에 많기 때문에 여기서는 기술적 개념 보다는 나의 생각을 적으려고한다.
1. React-query 전환 하게 된 계기
사업의 방향성을 전환하여 새로운 프로젝트를 진행하고 있었다. 이 프로젝트의 프론트엔드 구조는 현재 우리가 서비스를 제공하는 플랫폼의 프론트엔드 소스를 본떠 만들어 전역 상태관리는 Redux, Redux-thunk로 이루어져 있었다. 새로운 프로젝트 특성 상 고객의 요청에 따른 커스텀 기능을 가진 페이지를 만드는 일이 많아졌다. (A기업에 들어가는 페이지+기능, B기업에 들어가는 페이지+기능, C기업에 들어가는 페이지+기능이 모두 다르다는 것)
그러던 중 최근에 디자인 패턴, 폴더 구조에 관심이 생겨 찾아보던 와중에 현재 프로젝트의 Redux 구성이 불편하고 비효율적이라고 생각했고 이에 관련해서 slack에서 프론트엔드 팀원들과 논쟁을 하고 있었고, CTO님이 react-query나 swr을 적용해보자는 의견을 주셨다.
2. Redux 구성이 불편하고 비효율적이라고 느낀 이유
- 프로젝트의 Redux 구성은 action 타입, action 생성 함수, reducer, thunk 함수 등 정의해야할게 많았다.
- 커스텀 페이지가 많아질수록 점점 비대해지는 store, 복잡해지는 프로젝트 구조
- 프로젝트 구조가 복잡해질수록 의도치 않은 Side Effect 발생 확률 증가
- store가 상태관리를 위한 것인지, api 통신을 위한 것인지 구분이 힘들어진다. (순수한 전역 상태 관리로 사용되는 느낌이 없다)
- store는 전역 상태 관리인데, 각 커스텀 페이지의 각각의 페이지에서만 필요한 상태를 redux로 인해 전역 상태로 관리된다.
- server state와 client state의 구분 모호
위와 같은 이유들 중 store를 온전히 전역에서 사용되는 상태 관리로써 사용되지 않고 있다는 점이 가장 컸으며 추후에 react query 전환 레퍼런스를 찾다보니 나와 같은 고민을 우아한 형제들 FE팀에서 똑같이 했다는걸 보고 신기했고 나만 그렇게 생각한게 아니였구나 라는 생각이 들어 기뻤다. (우아한 형제들 레퍼런스는 아래에 주소 링크를 참조해놨다.)
3. React-query를 선택한 이유
- npm trend (사람들이 많이 사용하는 이유가 있을것이기 때문에)
- 이미 기업에서 사용하는 참고할 레퍼런스가 swr 보다 많았다.
My구독의 React Query 전환기
안녕하세요, 톡FE파트에서 My구독, 이모티콘 스토어를 개발하고 있는 Hugo입니다.My구독은 정기 결제를 통해 ‘이모티콘 플러스’, ‘톡서랍 플러스' 서비스를 이용할 수 있는 구독형 서비스입니
tech.kakao.com
※ 예전에야 swr은 devtools가 없었지만 지금은 devtools도 생긴데다가 redux 개선 목적으로 swr과 react query의 기술적 차이가 크지 않아 위 2가지 요소가 react query를 사용하게하는 가장 큰 계기가 되었다.
4. React-query 적용 및 느낀점
우선, 현재 프로젝트의 모든 redux 구조를 react-query로 전환하는 것은 프로젝트 일정 상 불가능했다.
그래서 커스텀 되는 페이지에서 먼저 적용해보기로 하였고, 내가 초기 셋팅을 하였다.
react-query를 처음 도입하게 되어 설레는 마음도 있었지만 초기 셋팅을 잘해야 한다는 압박관념에 react-query 관련 블로그, 유튜브를 다 본것 같다. 특히, 위에 링크된 우아한 형제들의 React-query 전환기 글의 저자분은 우아한테크 유튜브에서도 해당 글 관련 내용을 세미나 발표를 하셔서 도움이 많이 되었고, react-query를 공부하며 생긴 궁금증들이 해당 유튜브의 마지막 부분 Q&A에서 해결되었다.
이러한 과정에서 의도치 않게 나의 학습스타일이 나온것 같다.
대표적인 기능 및 설명을 블로그, 유튜브로 확인하고 실제 코드에 녹여보았고 필요한 기능의 다양한 옵션들, react-query의 컨셉을 알기 위해 react-query 공식 document를 찾아보며 학습하였고 초기 셋팅을 완료하였다.
하지만 내가 설정한 폴더 및 코드 구조보다 더 좋은 구조가 있는지 찾아보고 싶었고 기본적인 구조가 아닌 실제 사용하는 코드 및 폴더 구조를 중점으로 다시한번 github, 유튜브, 블로그에서 찾아보았다.
그 결과, custom hook 형태로 폴더 및 코드 구조를 바꿨으며, API 통신 로직 또한 services 폴더안에 각 도메인 별 서비스를 class로 묶어 관리하는 구조로 분리(이 구조를 보고 Spring의 service부분과 비슷하다고 생각했다.)하여 API 통신 로직, react-query 관련 로직, rendering component를 분리하여 각각의 역할은 각 파일에서 설정할 수 있게 되었다.
결과적으로, 나 뿐만 아니라 팀원들도 redux의 디자인 패턴보다 react-query를 이용한 디자인 패턴이 더 좋다고 느꼈다.
custom hook을 만들어 사용해서 그런지 훨씬 React스러워졌다.
5. Recoil을 사용하게 된 계기
초기에 여러 블로그를 찾아보면서 server state는 react-query로 client state는 recoil로 관리한다는 글을 보았다.
그 글을 읽었을 때에는 react-query에 대한 기술적인 개념 및 기초 사용법을 중점으로 여러 레퍼런스를 찾아볼 당시라 깊게 생각하지 않고 넘겼었는데 직접 개발을 하면서 위의 state 분리가 어떤걸 의미하는지 알게되었다.
예를 들어, 특정 api 로직으로 인해 페이지 전환이 이루어지고 난 직후에 액션이 필요할 때 client state가 필요했다.
기존 redux는 해당 component에서 store의 state를 가져왔지만 react-query로 전환을 하였으니 여기에서 store에서 state를 사용하기 위해 redux를 다시 정의한다는건 react-query를 사용하는 의미가 없다고 생각했다.
따라서, client state를 관리하기위해 mobx와 recoil을 고민하게 되었고 recoil을 사용한 이유는 다음과 같다.
- recoil은 react팀이 만들었으며 hook과 비슷한 react스러운 문법
- mobx에 비해 낮은 러닝 커브
위와 같은 장점이 있는 반면 recoil의 버전이 아직 1점대로 올라오지 않아 안정성에 대한 걱정 또한 있었다.
하지만 위의 걱정은 이미 다른 기업(토스, 카카오 등)에서 recoil을 사용중인것을 확인하고 사라졌다.
6. Recoil 적용 및 느낀점
recoil 또한 위의 react-query를 학습할 때와 같은 매커니즘으로 학습을 하였고 적용하였다.
적용하면서 정말 react스럽다고 느꼈고 러닝커브가 낮아 팀원들도 금방 쓸 수 있을것 같다고 느껴졌다.
기술적으로 어렵게 느껴지는게 없는 만큼 recoil 디자인 패턴을 중점으로 검색하였고 Atoms 폴더 안에 도메인별로 recoil atom을 관리하는 구조로 설정하였다.
7. React-query + Recoil 전환 후기
프로젝트가 커질수록 방대해지는 store를 막을 수 있었고 client state와 server state를 분리하게 되어 고구마를 먹다가 콜라를 먹은 기분이였다...
사실 처음엔 걱정도 많이 했다. 프로젝트에 새로운 기술을 도입한다는 것은 어느정도 책임감을 가지고 도입해야하기 때문이다.
프로젝트 일정이 빠듯하여 주말에도 작업을 하였지만 완성하고 나서 공유했을 때 주는 뿌듯함이 너무 좋다.
react-query + recoil 조합은 너무 좋은것같다.. 굉장히 맘에 들어 요즘에도 주말이나 퇴근 후 react-query, recoil 관련 유튜브, 블로그에 새로운 내용은 없는지 확인도해보고, 각각 공식 Document도 보면서 내가 몰라서 사용하지 않는 기능은 없는지, 새로운 기능은 어떤게 추가되었는지 확인한다.
현재 진행중인 프로젝트가 끝나고 시간이 남을 때 현재 사용중인 redux를 도메인별로 react-query로 전환하는 작업을 진행해야겠다.