5장. 리액트와 상태 관리 라이브러리

상태 관리는 왜 필요한가?

Flux 패턴의 등장

• 양방향 데이터 바인딩으로 인한 상태 변경 코드 추적이 어려움을 문제의 원인으로 판단, 단방향 데이터 바인딩 방식 도입
• action : 어떠한 작업을 처리할 액션과 그 액션 발생 시에 함께 포함시킬 데이터
• dispatcher : 액션을 스토어에 보내는 역할
• store : 액션의 타입에 따라 값을 어떻게 변경할지가 정의됨
• view : 스토어에서 만들어진 데이터를 가져와 화면을 렌더링

Redux

• Flux 구조를 구현한 라이브러리로, 데이터의 흐름을 단방향으로 강제함
• ELM 아키텍처 도입 : model, view, update
• 하나의 상태 객체를 스토어에 저장해두고, 이 객체를 업데이트하는 작업을 디스패치해 업데이트를 수행함
• props-drilling 문제 해결
• 하고자 하는 일에 비해 보일러플레이트가 너무 많다는 단점이 존재

Context API

• props-drilling 문제를 해결하고 싶지만, Redux의 보일러플레이트가 부담스러워 등장하게 된 기능
• 상태 주입을 도와주는 기능(상태관리X)으로, 렌더링을 막아주는 기능이 존재하지 않음

React Query, SWR

• HTTP 요청에 특화된 상태 관리 라이브러리

Recoil, Zustand, Jotai, Vatio

• 훅을 활용해 작은 크기의 상태를 효율적으로 관리

리액트 훅으로 시작하는 상태관리

• useState와 useReducer : 지역 상태로, 해당 컴포넌트 내에서만 유효하다는 한계 존재

• Recoil

  • atom(최소한의 상태 단위)은 key 값을 필수로 가짐

  • selector 함수를 사용해, 한 개 이상의 atom 값을 바탕으로 새로운 값을 조립할 수 있음

• Jotai

  • 작은 단위의 상태를 위로 전파하는 구조
  • Recoil의 한계를 보완한 라이브러리
    • Recoil의 atom 개념을 도입하면서도 API가 간결
    • Recoil과 달리 selector 함수 없이도 atom만으로 또 다른 파생된 atom 생성 가능
    • 타입이 잘 지원되며, 리액트 18의 변경된 API를 원활하게 지원
  • atom 생성 시, 별도의 key를 넘겨주지 않음 (객체를 키로 활용하는 WeakMap 방식 활용)

• Justand

  • 하나의 스토어를 중앙 집중형으로 활용해 스토어 내부에서 상태를 관리 (리덕스와 비슷)
  • partial : state의 일부분만 변경하고 싶을 때 사용
  • replace : state를 완전히 새로운 값으로 변경하고 싶을 때 사용
  • API가 복잡하지 않고 사용이 간단헤 쉽게 접근할 수 있음