[모투] React 상태관리 라이브러리 정하기

Chanyoung Park·2024년 3월 8일

사이드프로젝트 - [모투]

목록 보기

2/9

Action > Dispatcher > Store > View, 단방향의 Flux패턴
장점
- 중앙집중식 state관리로, 흐름제어와 디버깅 용이
- redux dev-tools로, 디버깅 용이
- 풍부한 커뮤니티
단점
- 불필요한 보일러플레이트
  - 보완 : redux-toolkit으로, 비동기처리, 보일러플레이트, action자동생성(~~예전에 사용할때 많이 힘들었음...~~)을 지원함
- 중앙집중식으로, 상태가 많을수록 복잡해짐

Context API를 개선한 라이브러리, atom과 selector개념
장점
- 러닝커브가 낮다 : 모든 블로그에서 설명하고 있다. atom과 selector만 알아도 상태관리를 할 수 있어, 다른 라이브러리보다 사용하기 쉽다. (물론, 간단한 기능의 경우에만...)
- 복잡하지 않은 구조 : atom -> selector -> component의 data-flow로, 복잡하지 않다.
- store와 같은 외부요인에 의존하지 않고, react내부의 context API를 활용하여, react사상에 더 알맞다.
- 동시성 : 데이터흐름이 다수 존재하는 경우, 렌더링동작 우선순위를 결정하여, 적절하게 렌더링해준다.
단점
- context API를 기반으로 하기 때문에, 함수형 컴포넌트에서만 사용가능하다.
- 복잡한 기능 구현 시, 복잡해진다. (중앙집중식으로, redux의 특징과 동일함)
- 디버깅 툴이 없다...

Observer와 Subscribe(구독)개념, 다수의 store존재
장점
- redux에 비해 간결하다. rtk이전에는 보일러플레이트때문에 mobx를 더 선호하기도 했다.
- 객체지향적 : store를 객체화(클래스화)하여 사용한다.
- 불변성 : 불변성 유지를 위한 별도의 라이브러리가 필요하지 않다.
단점
- 레퍼런스 부족
- 규모가 커지면, 로직이 mobx의 자동업데이트에 의존하여, 디버깅이 어려워짐
- validation구현에 있어 코드가 번잡하기로 알려져 있음

장점
- 매우 유연하여, 다른 상태관리 라이브러리와 쉽게 통합
- provider없는 구조
- 작은 번들사이즈
- redux-toolkit으로 디버깅 가능
단점
- 커뮤니티 부족 -> 성장하고 있는 라이브러리

redux
- 예전에는 보일러 플레이트의 문제로 많은 개발자들이 기피했지만, redux-toolkit으로 인해 사용하기 쉬워졌다. (이제는 사용해볼만 하다!)
recoil
- 규모가 작은 곳에 사용하기 간편하다.
mobx
- 소규모 적합
zustand
- 다른 상태관리와도 통합이 용이하고, 단점이 거의 없는 것 같다.

는 반진담 반농담이고, 사실 많은 개발자가 사용한다는 것은 그만큼 개발이슈가 많이 발생하고, 그 이슈를 해결해가며 라이브러리가 한층 성숙해졌을 것이다. 또한, 많은 사람들이 익숙하기에, 유사문제사례와 답변을 얻기에도 용이하다.

개발 라이브러리를 선택하는 데에 있어, 성능이 좋고 편한 것이 좋지만, 그만큼 중요한 것이 트러블 슈팅 대응과 best practice(사례)의 유무이다.
redux는 위에서 말한 것 중, 가장 오래되었고 많은 사람들이 사용 중이다. 또한, RTK로 이제는 사용하기 편해졌다.
recoil은 react사상에 가장 가깝지만 소규모에 적합하며, mobx/zustand는 단점이 거의 없지만, 많은 사람들이 사용중이지 않다. (redux에 비해)

context API는 React의 내장 API로, 중앙상태관리를 할 때 사용합니다.
하지만, Provider로 감싸는 형태로, 최상단 state가 변경되면, 상관이 없는 나머지 자식 컴포넌트들도 재렌더링되는 치명적인 단점을 가지고 있습니다.
이를 개선하기 위해 개발된 것이 recoil입니다.