상태관리 라이브러리를 사용하는 이유
•
React 는 부모→자식으로 단방향 데이터 흐름을 가집니다.
•
자식에서 부모의 상태를 바꾸려면 props 를 넘겨줘야하는데, “props drilling”을 해야하고, 그 과정에서 “props depth”가 증가해서 불필요한 리렌더링이 일어나게 되기에 비효율적입니다.
•
코드에서 데이터의 상태를 쉽게 관리하기 위해서 사용하게 됩니다.
상태관리 라이브러리들
Context API
•
React 가 자체적으로 가지고 있는 라이브러리
•
Context API 에서 제공하는 Provider 로 감싸진 부분은 업데이트가 되지 않은 state에서도 리렌더링 됩니다.
•
정적 데이터 위주로 처리하거나 업데이트가 빈번하지 않을 때 적합합니다.
•
불필요한 리렌더링을 보완하기 위해 Recoil 이 나왔습니다.
Redux
Redux - 자바스크립트 앱을 위한 예측 가능한 상태 컨테이너. | Redux
자바스크립트 앱을 위한 예측 가능한 상태 컨테이너.
https://ko.redux.js.org/
Redux 공식 사이트
•
최초 상태관리 라이브러리, 환경구성에 많은 코드가 필요합니다.
•
보일러플레이트 코드로 action, reducer, selector, store를 세팅합니다.
•
하나의 Store 만 가지고, 하나의 객체 트리를 가져서 디버깅이 쉽습니다.
•
store 내부 상태는 action이라는 객체에 의해서만 변경할 수 있습니다.
MobX
•
여러 개의 Store 를 생성할 수 있어서 분리가 편리할 수 도 있지만, 상태 변경 시 다수의 Store 가 영향을 받을 수 있습니다.
•
Redux 와 다르게 Store 의 데이터를 Action 발행 없이 업데이트할 수 있는데 이는 구현은 쉽고 용이하나 테스트나 유지보수의 측면에서 문제를 일으킬 수 있습니다.
•
유지보수 및 확장성을 고려해야 하는 프로젝트의 경우엔 MobX 는 좋지 않은 선택일 수 있습니다.
•
Redux보다 러닝커브가 낮고 보일러플레이트 코드의 양 또한 적어서 작은 프로젝트에선 MobX를 사용하는 것이 좋을 수 있습니다.
Recoil
•
페이스북에서 나온 최근 상태관리 라이브러리입니다.
•
Atom 과 Selector 로 구성됩니다.
•
해당 Atom을 구독하고 있으면 해당 컴포넌트들만 선택적으로 리렌더링이 됩니다.
•
Atom의 상태변화는 순수함수 ‘Selector’ 를 통해 할 수 있습니다.
•
Selector는 비동기 처리 뿐만 아니라 데이터 캐싱 기능도 제공하기 때문에 비동기 데이터를 다루기에 용이합니다.
•
상태를 분산적으로 둘 수 있어서 ‘코드 스플리팅’이 가능합니다.
◦
‘코드 스플리팅’: 코드에서 지금 사용하는 부분만 로딩하고, 필요하지 않은 코드는 분리시켜 나중에 로드함으로서 로딩 시간을 개선하는 것
•
큰 규모의 프로젝트에서는 도입하기 어려울 것 같지만, 아래처럼 라이브러리를 같이 사용하여 이점을 높입니다.
◦
Restful API 구현 시 → react-query(=TanStack Query, 데이터 CRUD) + recoil(상태관리)
◦
GraphQL API 구현 시 → apollo-client(데이터 CRUD) + recoil(상태관리)