[리액트 딥다이브] 5 리액트와 상태 관리 라이브러리(1)

5.1 상태 관리는 왜 필요한가?

상태: 애플리케이션의 시나리오에 따라 지속적으로 변경될 수 있는 값

- UI: 상호 작용이 가능한 모든 요소의 현재 값(다크/라이트 모드, input, 알림창 노출 여부)

- URL: 브라우저에서 관리되는 상태값(route params, query)

- form: loading, submit, disabled, validation

- 서버에서 가져온 값(API 요청)

 

5.1.1 리액트 상태 관리의 역사

기존에 사용되던 MVC 패턴은 모델과 뷰가 많아질수록 복잡도가 증가함

→ 상태 변화 추적이 어려움

 

페이스북 팀은 양방향 데이터 바인딩을 원인으로 봄

단방향 데이터 흐름을 제안 Flux 패턴의 등장

장점: 데이터 흐름 추적이 쉽고 코드 이해가 쉬워짐

단점: 사용자 인터렉션에 따른 데이터 갱신, 화면 업데이트 방법을 코드로 작성해야 하기 때문에 코드양이 많아짐

 

action: 작업을 처리할 액션과 액션에 포함시킬 데이터를 정의하여 디스패처로 보냄

dispatcher: 액션을 스토어에 보내는 역할(콜백 함수 형태)

store: 상태 값과 상태를 변경할 수 있는 메서드를 가짐

view: 리액트의 컴포넌트에 해당. 스토어에서 만들어진 데이터를 화면에 렌더링하는 역할

 

Flux 구조에 Elm 아키텍처를 도입한 리덕스의 등장

Elm: 웹페이지를 선언적으로 작성하기 위한 언어, 데이터 흐름을 셋으로 분류하고 단방향으로 강제

(model: 상태, view: html, update)

장점: prop drilling 해결, 어디서든 connect로 스토어에 접근 가능

단점: 보일러플레이트가 너무 많음(타입 선언, 액션 creator, dispatcher, selector 필요)

 

16.3 이전 context와 getChildContext()의 문제

- 상위 컴포넌트 렌더링 시 shouldComponentUpdate가 true를 반환하여 렌더링 발생

- context를 인수를 받으면서 컴포넌트와 결합도가 높아짐

 

상태 주입을 위한 Context API 출시

 

16.8 버전에서 다양한 훅 API가 추가되면서 HTTP 요청에 특화된 상태 라이브러리 ReactQuery, SWR 등장

 

Recoil, Jotai, Zustand, Valtio는 리덕스와 달리 훅을 활용해 작은 크기의 상태를 효율적으로 관리

(리액트 16.8 이상을 요구)

 

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

5.2.1 가장 기본적인 방법: useState, useReducer

상태가 복잡하거나 상태 변경 시나리오가 다양하다면 코드를 훅으로 격리하여 제공, 재사용

지역 상태라는 한계

여러 컴포넌트에서 공유하기 위해서 컴포넌트 트리를 재설계해야 함

 

5.2.2 useState 지역 상태의 한계를 벗어나보자

함수 외부에서 상태를 참조하고 렌더링을 자연스럽게 일어나게 하려면

1. 컴포넌트 외부에 상태를 두고 여러 컴포넌트가 같이 쓸 수 있어야 함

2. 상태를 사용하는 컴포넌트는 상태 변화를 감지하여 리렌더링을 일으켜야 함

3. 상태가 객체인 경우 변하지 않은 값에 의해 리렌더링이 발생하지 않아야 함

 

5.2.3 useState와 Context를 동시에 사용해보기

5.2.2에서 구현한 방법은 하나의 스토어만 가지게 됨

동일한 구조로 여러 스토어를 만들고 싶은 경우 context와 같이 사용