Zustand

도입 배경

겪은 문제

• 우리가 사용한 라이브러리인 React 는 부모 컴포넌트에서 자식 컴포넌트로 props 를 내려주는 단방향 바인딩 구조를 가지고 있습니다.
• 컴포넌트 수가 늘어나고, 컴포넌트간 계층이 깊어지면 하위 컴포넌트에 props 를 내려주는 과정에서 여러가지 문제가 있습니다.
  • props 를 사용하지 않는 컴포넌트에서도 더 하위에 있는 컴포넌트로 props 를 내려주기 위해 가지고 있어야 하는 문제가 있습니다.
  • props 의 수가 늘어나면 관리해야 하는 props 가 많아져 유지보수 하기 어렵습니다.

Context API

장점

• React 자체 지원

단점

• 상태관리를 위해 사용할 경우 성능적인 이슈 발생
  • 불필요한 재랜더링
  • 최적화를 위한 Provider Hell 문제

Redux

장점

• 디버깅을 위한 Redux DevTools 지원
• Flux 패턴
  • 중앙 집중형 스토어
  • 단순한 데이터 플로우
  • 쉬운 결과 예측
• 낮은 React 와의 결합도

단점

• 번거로운 보일러플레이트
  • Action 이 늘어날수록 관리해야 할 코드의 양이 많음
• 높은 러닝커브
• 서드파티 라이브러리 필요

Recoil

MobX

• 데코레이터 제공
• 적은 보일러 플레이트
• (특징) 객체지향적 코드
• Spring 과 비슷한 매커니즘으로 서버 개발자에게 유용

Zustand

장점

• 미들웨어를 통해 Redux Devtools 호환
• 적은 보일러플레이트
• 낮은 러닝커브
  • Zustand 핵심 로직 소스코드: 42줄
• 낮은 React 와의 결합도
  • Provider 로 감싸지 않아도 됨
• 100% TS로 구현

단점

• 자체 DevTools를 지원하지 않음