리액트에서 상태 관리는 굉장히 중요한 부분이다. 그렇기에 Redux, MobX, recoil, jotai 등등... 많은 상태 관리 라이브러리들이 출시되어 사용되어지고 있다. 나는 2차 프로젝트에서 Client State는 Zustand, Server State는 React-query를 통해 관리하였다. 어떠한 목적성을 위해 선택했다기보다는 현재 FE 생태계에서 가장 HOT한 녀석들을 선택해서 사용하였다. 하지만 프로젝트와 리팩토링 과정들을 거치며 내가 느낀 리액트 쿼리의 장점과 사용해야 하는 이유에 대해 기록해 보고자 한다.
효율적인 상태관리
최근 UI/UX의 중요성이 강조되고 기능이 고도화됨에 따라 코드 규모가 커지고 프론트엔드에서 수행하는 역할이 늘어나고 있다. 이는 곧 관리해야 하는 상태가 많아짐을 의미하기도 한다. 상태 값도 Client State와 Server State 두 가지로 나뉘는데 각각의 특성이 다르다.
Client State 특징
- Ownership이 Client에 존재
- 다른 사람들과 공유되지 않으며 Client 내에서 UI/UX 흐름이나 사용자 인터렉션에 따라 변할 수 있다.
- 항상 Client 내에서 최신 상태로 관리된다.
Server State 특징
- Ownership이 Server에 존재
- Client에서 관여할 수 없는 원격의 공간에서 관리되고 유지된다. ex) Database
- State값을 읽어오거나, 업데이트 시 비동기 API가 필요하다.
- 다른 사람들과 공유되는 것으로 내가 모르는 사이에 변경될 수 있다.
- 신경 쓰지 않는다면 잠재적으로 'out of date'가 될 가능성이 있다.
이러한 특징들 때문에 리액트 쿼리를 이용해서 Server State를 관리하면 데이터 캐싱, refetching, invalidate 등의 기능들을 통해 보다 간결한 코드로, 효율적인 상태 관리가 가능하다.
리덕스와 같이 중앙관리 시스템인 경우는 상태 관리 로직과 API 통신 로직이 반복되면서 코드의 관심사 분리가 힘들어지는 경우가 있는데, 리액트 쿼리를 통해 Server State만을 따로 관리하게 되면 관심사 분리가 되어 코드 퀄리티가 향상된다. 결국 Client에서는 UI/UX에 관여하는 상태 값, 유저 정보에 대한 상태 값 등 적은 양의 상태만 관리하게 된다.
낮은 러닝커브
상태 관리 라이브러리를 결정할 때 낮은 러닝커브도 큰 영향을 줬다. 부트캠프 과정 중 Redux를 배웠지만 사용법이 어려웠고, 새로운 라이브러리를 도입하자니 다시 공부해야 된다는 부담감이 있었지만, 리액트 쿼리, Zustand를 살펴본 결과 사용법이 굉장히 간결하여 채택하게 되었다. 리액트 쿼리 공식 문서에서도 zero-config를 강조하고 있는데 그냥 사용해도 충분히 파워풀 하지만, 몇몇 옵션들을 커스텀 해서 사용하면 굉장히 효율적으로 사용할 수 있다.
사용법이 간결한 것과 우리가 효율적으로 사용했냐는 다른 이야기이지만 Server State를 Client에서 다시 상태 값으로 관리하는 비효율성은 최대한 피하고자 했고, store 폴더를 만들어 상태들을 모듈화하여 효율적으로 관리하고자 노력했다.
zero-config
- Quries에서 캐싱 데이터는 언제나 stale 취급
staleTime 설정을 통해 controll 가능 - 각 시점에서 data가 stale이라면 항상 refetch 발생
reFetchOnMount, refetchOnWindowFocus, refetchOnReconnect 설정을 통해 controll 가능 - inactive Query들은 5분 뒤 GC에 의해 처리
cacheTime 설정을 통해 controll 가능 - Query 실패 시 3번까지 retry
retry, retryDelay 설정을 통해 controll 가능
고급스러운 비동기와 에러처리
리펙토링 과정에서 Suspense를 통해 API 비동기 처리, ErrorBoundary를 통해 에러를 처리했다. 하나의 컴포넌트에서 모든 것을 다뤄야만 했는데 리액트 쿼리, Suspense, ErrorBoundary 세 가지를 이용해 관심사 분리를 할 수 있었다. 이때 리액트 쿼리의 옵션 (useErrorBoundary, suspense)을 설정해서 편리하게 구현할 수 있었다. Suspense와 ErrorBoundary에 대한 내용은 따로 포스팅하도록 하겠음!!
나의 생각.
프로젝트 때 리액트 쿼리의 파워풀함을 경험하고 나서 이를 더 잘 사용하고 싶다는 욕심이 생겼다. 리액트 쿼리를 사용할 때 코드 컨벤션은 어떻게 되는지, 어떤 식으로 사용해야 효율적인지, 비동기 처리를 고급 지게 처리할 수 있는 방법들이 더 있을지 등등... 궁금한 게 많아졌다. 마침 이번 원티드 프리온보딩 주제가 리액트 쿼리여서 신청하고 열심히 수강할 예정이다. 또한 사이드 프로젝트에도 적용해 보고 열심히 학습해서 다른 사람이 봤을 때 좀 치내?라고 생각할 수 있도록 하는 게 목표.
