새 프로젝트 웹소켓을 활용한 여행 플래너 개발을 위한 상태관리 라이브러리로 어떤 걸 사용할 지, 대표적인 4가지 Redux, Recoil, Zustand, Jotai 의 각 장단점을 조사해봤다
결론
서버 데이터 상태 관리 : react query 사용
클라이언트 데이터 상태 관리 : Recoil 사용
공통 장점
- 컴포넌트에서 글로벌 상태의 특정 값을 의존하게 될 때 해당 값이 바뀔 때에만 리렌더링이 되도록 최적화가 되어 글로벌 상태 중 의존하지 않는 값이 바뀌게 될 때에는 컴포넌트에서 낭비 렌더링이 발생하지 않는다
- 타입스크립트 지원 O
다른 상태관리 라이브러리들 중 가장 사용 방법이 복잡하다
보일러플레이트 코드(변화없이 여러 군데에서 반복되는 코드)가 많다.
→ Redux Toolkit을 사용하면 리듀서, 액션타입, 액션 생성함수, 초기상태를 하나의 함수로 선언 할 수 있다.
비동기 요청을 위한 Redux-thunk, Redux-Saga 등의 서드파티 라이브러리가 필요하다
→ react-query 로 API 요청에 대한 처리가 쉽게 가능하다.
새로 고침 시 리덕스의 store의 state가 날아간다
→ redux-persist
를 설치하여 localStorag 또는 session Storage에 저장가능하다
Recoil, Zustand, Jotai 중 유일하게 Hook 기반이 아니다
전역 상태 관리 라이브러리 중 여전히 다운로드 수 1위로 사용하는 곳이 많다
Redux를 잘 다룰 줄 알면, Redux를 기반으로 만들어진 다른 라이브러리(Zustend 등)도 금방 익힐 수 있다
모든 상태 업데이트를 액션으로 정의하고, 액션 정보에 기반하여 리듀서에서 상태를 업데이트하기 때문에 상태를 더욱 쉽게 예측 가능하게 하여 유지보수 측면에 긍정적인 효과가 있다
Redux Devtools
를 이용해 직관적으로 전역 상태들을 볼 수 있다. 전역으로 관리해야 하는 상태값이 많아질 경우 디버깅이 편하다.
컴포넌트가 아닌 곳에서 글로벌 상태를 사용하거나 업데이트를 해야 할 때 (WebSocket을 사용 또는 리액트 네이티브 브릿지에서 연동을 할 때) getState
또는 dispatch
를 바로 호출해서 사용하면 꽤 유용한 상황이 있기도 하다.
→ 아직 잘 와닿지 않는다. WebSocket
을 직접 사용해봐야 알 것 같다.
서버 사이드 렌더링이 가능하다. 서버 요청에 대한 응답과 함께 앱의 상태를 서버로 전송하여 앱의 초기 렌더링을 처리 할 수 있습니다.
Redux
처럼 따로 안정적인 Devtool이 없어 디버깅이 상대적으로 불편하다
어느 컴포넌트라도 전역상태에 직접 접근하여 상태를 업데이트할 수 있기 때문에 어느 컴포넌트가 언제 전역 상태를 변경하는지 알기 어렵다.
새로 고침하면 Recoil State가 증발한다
→ recoil-persist 라이브러리를 사용하면 recoil state가 날라가지 않고 sessionStorage
또는 localStorage
에 보관된다.
페이스북팀에서 실험단계에서 더 이상 업데이트를 안하는 것 같다(?)
Selctor
는기본적으로 들어왔던 적이 있는 값을 기억하고 있기 때문에(= 캐싱), 같은 응답을 보내는 api call에 대해서는 추가적으로 요청하지 않아 성능적으로 유리하다.Suspense
와 같이 사용할 수 있다. 컴포넌트에서는 selector
의 비동기 데이터를 기다리는 동안 로딩 상태를 손쉽게 보여줄 수 있다.Error Boundary
로 손쉽게 selector
에서 던져진 에러를 잡아서 처리할 수 있다.waitForAll
API를 사용해서 동시에 요청할 수 있다.단순 사용은 정말 쉬운데 그 외 zustand에 들어있는 기능들을 사용하기 위해 공부할 수 있는 최신 한글 자료가 많이 없다.
블로그에 번역본 기사들이 올라와있긴 한데, 1 ~ 3년 전 글이고, 번역도 완벽하지 않아서 잘 걸러서 봐야한다
Zustand와 마찬가지로 공신력 있는 한글 자료가 많이 없다
💡 면접 대비를 위한 CS tip : 상태관리에 대한 3가지 접근 방식
① Flux
➁ Proxy
➂ Atomic
references
좋은 글 감사합니다 👏