상태 관리 라이브러리 선택하기

상태관리라이브러리로 zustand와 react query를 사용하고자 하는 이유를 작성했습니다.

상태는 사용하는 곳과 최대한 가까워야 하며 사용 범위를 제한해야 합니다.

그러나 트리를 통해 prop을 깊이 전달해야 하거나, 많은 구성 요소가 동일한 prop을 필요로 하는 경우 props drilling이 발생하는데, 이를 해결하고자 지역 상태를 해당 컴포넌트들 사이의 전역 상태로 공유합니다.

전역 상태 관리 방법으로는 Context API + useState 또는 useReducer를 이용하거나 외부 상태 관리 라이브러리를 활용하는 방법이 있습니다.

상태 주입을 도와주는 기능(상태관리 X)으로, 렌더링을 막아주는 기능이 존재하지 않음

React 컴포넌트 트리를 통해 데이터를 전달하고 공유하기 위한 방법을 제공하는 API
- React 컴포넌트 트리 안에서 글로벌하게 데이터를 공유할 수 있도록 함
- Context 사용 시 부모 컴포넌트가 props를 통해 명시적으로 전달하지 않고도 자식 컴포넌트에 정보 제공 가능 (depth 상관 X)
- 전역적으로 공유해야 하는 데이터를 컨텍스트로 제공하고 해당 컨텍스트를 구독한 컴포넌트에서만 데이터를 읽을 수 있게 함
유틸리티 함수를 정의하여 더 간단한 코드로 컨텍스트와 훅을 생성해 생산성을 증가시킵니다.
전역 상태를 관리하기 위한 솔루션이라기보다 여러 컴포넌트 간에 값을 공유하는 솔루션에 가깝습니다.
- useState나 useReducer와 같이 지역 상태를 관리하기 위한 API와 결합하여 상태 관리
Context API를 사용하여 전역 상태를 관리하는 것은 대규모 애플리케이션이나 성능이 중요한 애플리케이션에서 권장되지 않습니다.
- Context Provider의 props로 주입된 값이나 참조가 변경될 때마다 해당 컨텍스트를 구독하고 있는 모든 컴포넌트가 리렌더링되기 때문
- 애플리케이션이 커지고, 전역 상태가 많아질수록 불필요한 리렌더링과 상태의 복잡도가 증가

이러한 점들로 인해 client-state는 Zustand를, server-state는 React Query를 사용해 상태관리를 도입하고자 합니다.

Zustand

Zustand는 아래와 같은 다양한 장점을 가지고 있습니다.

적은 보일러 플레이트
- Flux 패턴을 사용하여 많은 보일러플레이트를 가지지 않는 훅 기반의 편리한 API 모듈을 제공
직관적인 사용법
- API가 복잡하지 않고 사용이 간단해 쉽게 접근 가능
- 상태와 상태를 변경하는 액션을 정의하고 반환된 훅을 어느 컴포넌트에서나 임포트하여 원하는대로 사용
작은 패키지 사이즈
특정 라이브러리에 종속되지 않음
- 클로저를 활용해 하나의 스토어를 중앙 집중형으로 활용해 스토어 내부에서 상태를 관리(리덕스와 비슷)
  - partial : state의 일부분만 변경하고 싶을 때 사용
  - replace : state를 완전히 새로운 값으로 변경하고 싶을 때 사용

마찬가지로 Redux와 Zustand를 비교한다면, Zustand는 Store 구현 시 더 간단하게 구현이 가능하며 Flux 패턴을 단순화해 러닝 커브를 줄였습니다.

Store를 구현하려면?
- Redux : Store 및 State 선언, Action 선언, Reducer 구현, Provider 연결, 컴포넌트 연결
- Zustand : Store에 모두 구현, 컴포넌트에서 호출

React Query는 강력한 비동기 상태관리 도구이며 아래와 같은 다양한 장점을 가지고 있습니다.

예전에는 Redux로 API 호출을 했지만, React Query의 경우 Polling을 잘 다룰 수 있다는 이점 또한 있습니다.

API 호출 코드에 Polling을 구현하려면?
- Redux : Action 선언, State 추가, Reducer 대응, sage 폴링 구현, 컴포넌트 연결
- React Query : Query 선언 + 옵션
API 호출 상태를 알고 싶다면?
- Redux : State 추가, Reducer 대응, 컴포넌트 연결
- React Query : Query에서 제공