jotai vs zustand

Jotai

• 핵심 컨셉
  Jotai는 기존의 우리가 쓰던 일반적인 전역 상태 라이브러리와는 조금 다른 패턴을 사용하는 라이브러리이다.
  일반적으로 Primitives라고 하는 이름을 쓰는데, atom이라는 가장 작은단위를 생성, 관리, 제어 하는 여러가지 함수를 통해 전역으로 상태를 관리한다.
  React의 useState와 매우 유사하게 작동하는 “Atom”이라는 개념을 통해 상태를 정의하고, 컴포넌트에서 구독해 사용할 수 있다.
  다른 상태 관리 라이브러리에 비해 러닝 커브가 상대적으로 낮고, React 18에서 더 많이 활용되고 있는 Suspense 기능 등과 통합하기가 편하다는 장점이 있다.

• 장점

  1. 직관적인 API: useAtom() 훅을 사용하여 Atoms를 구독하며, 다양한 형태로 상태를 구성할 수 있다.
  2. 컴포넌트별 구독: 필요한 상태만 구독하므로, 전체 리렌더링을 최소화한다.
  3. 복잡한 상태도 관리 가능: Computed atoms(파생 상태)나 async atoms를 통해 비동기 로직이나 다른 atom의 상태를 기반으로 하는 논리를 깔끔하게 정리할 수 있다.

• 단점

  1. Atom 관리의 복잡성: atom 자체는 간단하지만 여러개의 atom을 관리하는 것은 쉽지 않다.
  2. 복잡해질 수 있는 애플리케이션 구조에서 여러 개의 atom을 만들어야 할 때, atom 정의/구조를 적절히 관리하지 않으면 혼란스러울 수 있다.

Zustand

• 핵심 컨셉
  Zustand는 Redux 같은 Flux 패턴을 조금 단순화한 느낌이다.
  dispatch가 없고 그냥 특정 상태를 구독하면 해당 상태의 함수를 호출 할 수 있다.

• 장점

  1. 최소한의 보일러플레이트: Redux와 달리 Action, Reducer 등의 복잡한 구조가 필요 없다.
  2. 그 외 redux가 가지고 있는 장점들을 대부분 공유한다.

• 단점

  1. 선언적/명령적 패턴 혼용: React에서 모달 등 UI 요소를 선언적 접근으로 처리하는 것과 Zustand의 로직/데이터 처리가 맞물릴 때, 구조를 어떻게 짤지 고민이 필요할 수 있다.
     1. 이부분이 조금 복잡한데, react는 상태 기반으로 동작하기에 선언적이라고 할 수 있다.
     2. isOpen은 false일때 팝업이 안보이고 true일때 보이도록 되어있다.
     3. 그러나 zustand는 함수 호출 기반으로 상태가 업데이트되기때문에 명령적이다.
     4. 예를들어 모달을 여러개 띄워야 하는경우 isOpen 함수만으로는 어떤 모달을 닫아야 하는지 헷갈릴 수 있다. 선언적인 경우 여러개의 상태를 추가하거나 동적으로 처리할 수 있다.

비교 항목	Jotai	Zustand
구조 관리	여러 atom(원자)로 상태를 세분화할 수 있으나, 원자 관리 필요	하나의 스토어에서 상태를 정의하되, 커질 경우 모듈화 전략 필요
확장성	Recoil과 비슷한 구조로, React Suspense 사용 가능	redux와 비슷한 구조

정리

1. jotai는 여러개의 atom을 특정 기능을 위해 조합하여 사용하는 개념
2. zustand 는 거대한 하나의 트리의 일부를 가져다가 쓰는 개념

---

결론

2개 다 redux보다 훨씬 더 간결하고 편하다. 둘다 요새 트랜드다.
zustand가 조금 더 인기는 많은 것 같다.
jotai가 조금 더 늦게 나왔기 때문에 조금 더 트랜디하고,
suspense, dehydration 등 편리한 기능들을 더 제공하고 있다.
웹의 특성 상 어차피 zustand든 다른 전역상태관리라이브러리가 나오든 저 2개의 기능은 추가될것이다.

• 결국은 큰 차이없다
• 새로운 패턴, 트랜디한거 쓰고싶으면 jotai
• 익숙한 패턴, 트랜디한거 쓰고싶으면 zustand
  • 이건 다시말해 best practice