서론
프로젝트의 프론트 상태가 크게 복잡하지 않아
데이터 페칭 라이브러리(혹은 서버 스테이트 관리 라이브러리)인 SWR를 사용해 상태를 관리하고 있었다.
하지만 Item Detail 페이지에 Comment, Chart등 컴포넌트 깊이가 깊어지고, static data(GetStaticProps로 가져온 데이터)를 최초 렌더링 시 반영하기 위해서는 props drilling이 필수불가결해졌다.
따라서 이번 기회에 프론트 상태관리 라이브러리를 도입하고자 하였고, 그 진행상황을 기록해보았다.
1. 어떤 상태관리 라이브러리를 사용해야 할까?
Redux?
가장 먼저 도입을 고려한 라이브러리는 Redux였다. 보일러 플레이트가 많긴하지만 Redux-tool-kit을 사용하면 될 것이라 생각하였다.
하지만 여러 시행착오 끝에 다음과 같은 이유로 Redux는 사용하지 않기로 결정하였다.
- 구조
Redux에서 비동기데이터를 처리해야할 경우 Redux-saga가 필수적이며, isLoading, isSuccess, isError등의 처리를 직접 구현해주어야 한다. 이 기능들은 모두 SWR을 사용한다면 기본적으로 제공하는 기능들이다.
또한 간단한 API 추가에도 Action, Reducers, Sagas 등 많은 추가작업이 뒤따르게 된다.
- 데이터 구분
또한, 페이지 내에서 사용하는 데이터를 서버 데이터, 클라이언트 데이터로 구분하였을 때, 실제로 프론트에서만 사용되는 클라이언트 데이터는 많지 않은데, Redux를 사용하게 되면 일부 클라이언트 데이터로 인해 모든 서버 데이터들도 Redux를 거치게 되어 불필요한 작업이 늘어난다.
- 에러 처리
별도의 에러 처리 로직을 직접 구성해야한다.
RTK-query, Apollo, Tanstack-query?
RTK-query는 결국 Redux 구조를 따라야한다는 한계가 있다.
Apollo는 별도로 스키마를 정의해야 한다.
Tanstack-query를 도입할 수도 있었지만, 이미 SWR을 사용하고 있는 상황에서 굳이 Tanstack-query로 갈아탈 이유를 찾지 못했으며, 결정적으로 클라이언트 번들 사이즈가 늘어난다는 점을 고려해 SWR을 계속 사용하기로 결정하였다.
ContextApi + SWR!
따라서 기존에 사용하던 서버 스테이트 관리 라이브러리인 SWR를 기본으로 하고
ContextApi를 추가하여 Props drilling을 해결하기로 결정하였다.
한계
- Mutation이 여러번 일어날 경우 Wrapper 함수 필요
- 비즈니스 로직이 완벽히 분리되지 않는다.
Ref
