결론
어차피 API 요청 처리를 위해 react query를 사용한다면 전역 상태관리 라이브러리는 쉬운 걸 쓰는 게 좋은 것 같아서 Jotai 가 편할 것 같다.
학습을 위해서라면 Redux 나 Recoil 사용이 좋은 것 같다.
조사한 내용
상태관리 라이브러리 공통 장점
1.
컴포넌트에서 글로벌 상태의 특정 값을 의존하게 될 때 해당 값이 바뀔 때에만 리렌더링이 되도록 최적화가 되어 글로벌 상태 중 의존하지 않는 값이 바뀌게 될 때에는 컴포넌트에서 낭비 렌더링이 발생하지 않는다
2.
타입스크립트 지원 O
단점
1.
다른 상태관리 라이브러리들 중 가장 사용 방법이 복잡하다
•
컴포넌트와 액션 사이의 연결을 설정하는 작업이 번거롭다
2.
보일러플레이트 코드(변화없이 여러 군데에서 반복되는 코드)가 많다.
→ Redux Toolkit을 사용하면 리듀서, 액션타입, 액션 생성함수, 초기상태를 하나의 함수로 선언 할 수 있다.
3.
비동기 요청을 위한 Redux-thunk, Redux-Saga 등의 서드파티 라이브러리가 필요하다
•
리덕스로 요청에 관련된 상태를 관리하려면 요청 시작, 요청 성공, 요청 실패에 대한 3가지 액션들을 준비해야 하고 해당 액션들을 처리하는 로직들도 필요하다
→ react-query 로 API 요청에 대한 처리가 쉽게 가능하다.
4.
새로 고침 시 리덕스의 store의 state가 날아간다
→ redux-persist 를 설치하여 localStorag 또는 session Storage에 저장가능하다
5.
Recoil, Zustand, Jotai 중 유일하게 Hook 기반이 아니다
장점
1.
전역 상태 관리 라이브러리 중 여전히 다운로드 수 1위로 사용하는 곳이 많다
2.
Redux를 잘 다룰 줄 알면, Redux를 기반으로 만들어진 다른 라이브러리(Zustend 등)도 금방 익힐 수 있다
3.
모든 상태 업데이트를 액션으로 정의하고, 액션 정보에 기반하여 리듀서에서 상태를 업데이트하기 때문에 상태를 더욱 쉽게 예측 가능하게 하여 유지보수 측면에 긍정적인 효과가 있다
4.
Redux Devtools를 이용해 직관적으로 전역 상태들을 볼 수 있다. 전역으로 관리해야 하는 상태값이 많아질 경우 디버깅이 편하다.
5.
컴포넌트가 아닌 곳에서 글로벌 상태를 사용하거나 업데이트를 해야 할 때 (WebSocket을 사용 또는 리액트 네이티브 브릿지에서 연동을 할 때) getState 또는 dispatch를 바로 호출해서 사용하면 꽤 유용한 상황이 있기도 하다.
→ 아직 잘 와닿지 않는다. WebSocket 을 직접 사용해봐야 알 것 같다.
6.
서버 사이드 렌더링이 가능하다. 서버 요청에 대한 응답과 함께 앱의 상태를 서버로 전송하여 앱의 초기 렌더링을 처리 할 수 있습니다.
API 요청 관리 : React query 로 또는 RTK Query ?
•
둘 다 state 변경에 따라 자동으로 다시 데이터를 불러올 수 있고, 캐싱이 가능하다
•
RTK Query 보다 React query에 useInfinite query 등 기능이 더 많다
•
RTK Query에 대한 러닝 커브가 있다
단점
1.
Redux처럼 따로 안정적인 Devtool이 없어 디버깅이 상대적으로 불편하다
2.
어느 컴포넌트라도 전역상태에 직접 접근하여 상태를 업데이트할 수 있기 때문에 어느 컴포넌트가 언제 전역 상태를 변경하는지 알기 어렵다.
•
기능이 점차 추가되고 전역상태가 늘어나면서 여기저기서 상태를 업데이트하게 되면 점점 상태 변경을 예측하기가 어려워진다. (유지 보수도 어려움)
3.
새로 고침하면 Recoil State가 증발한다
→ recoil-persist 라이브러리를 사용하면 recoil state가 날라가지 않고 sessionStorage 또는 localStorage에 보관된다.
4.
페이스북팀에서 실험단계에서 더 이상 업데이트를 안하는 것 같다(?)
장점
1.
useState 훅과 비슷하게 동작하는, 직관적이면서 간단한 구조를 가지고 있다.
•
Redux 대비 보일러플레이트 코드가 적고 사용이 간편하다
2.
Selector로 비동기 처리가 가능하다. (redux 처럼 따로 미들웨어를 설치할 필요가 없다)
•
Selector의 특징
◦
Selector는 순수 함수여야 하고, Promise를 반환해야 한다
◦
Selctor 는기본적으로 들어왔던 적이 있는 값을 기억하고 있기 때문에(= 캐싱), 같은 응답을 보내는 api call에 대해서는 추가적으로 요청하지 않아 성능적으로 유리하다.
◦
React Suspense와 같이 사용할 수 있다. 컴포넌트에서는 selector의 비동기 데이터를 기다리는 동안 로딩 상태를 손쉽게 보여줄 수 있다.
◦
React Error Boundary로 손쉽게 selector에서 던져진 에러를 잡아서 처리할 수 있다.
◦
여러 개의 비동기 쿼리를 waitForAll API를 사용해서 동시에 요청할 수 있다.
Zustand
장점
1.
redux의 Redux DevTools 로 디버깅이 가능하다
2.
보일러플레이트가 적고 redux 보다 사용이 쉽다
•
provider 필요없음 → 앱을 래핑하지 않아도 되기 때문에 불필요한 리렌더링을 최소화한다
3.
Hook 기반으로 만들 수 있다
단점
단순 사용은 정말 쉬운데 그 외 zustand에 들어있는 기능들을 사용하기 위해 공부할 수 있는 최신 한글 자료가 많이 없다.
블로그에 번역본 기사들이 올라와있긴 한데, 1 ~ 3년 전 글이고, 번역도 완벽하지 않아서 잘 걸러서 봐야한다
Jotai
장점
1.
사용이 쉽다
2.
단순 저장소 기능 외에도 비동기 액션 처리 기능들이 내재되어 있다
a.
atom.onMount : atom 이 provider에 처음 사용되는 시점을 활용
b.
Async 간단한 비동기 액션 처리 가능
c.
Suspense와 함께 사용 가능
d.
Suspense를 사용하지 않고 fetching 상태를 직접 관리도 가능 (loading, error, data … 등)
e.
atom을 위한 Provider를 제공하는데, Provider가 없는 모드도 가능
단점
Zustand와 마찬가지로 공신력 있는 한글 자료가 많이 없다
•
화해 블로그 글도 2021년 작성된 글
더 찾아볼 내용
면접 대비를 위한 CS tip : 상태관리에 대한 3가지 접근 방식① Flux
•
저장소(store) / 액션함수(action) / 리듀서 등을 통해서 상태를 업데이트 하는 방식
•
Redux, Zustand
➁ Proxy
•
컴포넌트에 사용되는 일부 상태를 자동으로 감지해서 업데이트 하는 방식
•
Mobx, Valtio
➂ Atomic
•
React에 사용되는 state와 비슷하게 리액트 트리 안에서 상태를 저장하고 관리하는 방식
•
Recoil, Jotai