React State Management
목차
- 시작하며(Getting Started)
-
기본기능(Basic Features)
a. 페이지들(Pages)
b. Data Fetching - Context-API
a. 장점 b. 단점 c. 이럴 때 사용하세요 - Redux a. 장점 b. 단점 c. 이럴 때 사용하세요
- Recoil
- React-Query
- Redux
- Mobx form 과 같이 값을 관찰해야할 때 (observable)
- Recoil
- React-Query
- useSWR
시작하며(Getting Started)
React는 A → B (B ← A 는 안된다) 라는 단방향의 디자인 패턴, Flux를 지향하고 있다. 따라서 이럴 때 생기는 문제, 증조할아버지(?) 컴포넌트에서 증손자(?) 컴포넌트까지 데이터를 props로 넘겨주려면 여러 단계 걸쳐서 줘야하는 props drill이라는 현상이 발생된다. 따라서 이를 해결하고자 여러가지 상태 관리 매니지먼트가 있다.
Context-API (useReducer)
전역적(gloabal)인 데이터를 공유할 수 있도록 고안된 방법이다.
</img>
b. 장점
- 별도의 라이브러리가 필요 없다.
- 간단하다
c. 단점
- Provider 안에 포함된 모든 컴포넌트가 리렌더링이 되어 성능 최적화에 방해가 된다. (useMemo를 사용하거나 상태값/액션을 나눌 수 있지만 좋은 구조는 아니다)
- Context 추가할 때마다 Provider 로 매번 감싸줘야하기 때문에 Provider hell 을 야기할 수 있다.
d. 이럴 때 사용하세요
- low-freqeuncy, 즉 낮은 빈도로 상태값이 변경할 때.
- 로그인 정보 또는 웹사이트 내에 사용자 설정 파일, 테마, 언어, 모달(Modal), 알림창(Alert) 등 상태값이 자주 바뀌지 않는 경우, 컴포넌트 간 간단한 공유 데이터에 사용됩니다.
- 즉 Child Component가 많지 않을 때 사용하는 것을 추천한다
Context-API
리액트 16.3 버전부터 전역적(gloabal)인 데이터를 공유할 수 있도록 Context Api 새로 고안되었다.
</img>
b. 장점
- 별도의 라이브러리가 필요 없다.
- 간단하다
c. 단점
- Provider 안에 포함된 모든 컴포넌트가 리렌더링이 되어 성능 최적화에 방해가 된다. (useMemo를 사용하거나 상태값/액션을 나눌 수 있지만 좋은 구조는 아니다)
- Context 추가할 때마다 Provider 로 매번 감싸줘야하기 때문에 Provider hell 을 야기할 수 있다.
d. 이럴 때 사용하세요
- low-freqeuncy, 즉 낮은 빈도로 상태값이 변경할 때.
- 로그인 정보 또는 웹사이트 내에 사용자 설정 파일, 테마, 언어, 모달(Modal), 알림창(Alert) 등 상태값이 자주 바뀌지 않는 경우, 컴포넌트 간 간단한 공유 데이터에 사용됩니다.
- 즉 Child Component가 많지 않을 때 사용하는 것을 추천한다
Redux
전역적(gloabal)인 데이터를 공유할 수 있도록 고안된 방법이다.
</img>
b. 장점
- 별도의 라이브러리가 필요 없다.
- 간단하다
c. 단점
- Provider 안에 포함된 모든 컴포넌트가 리렌더링이 되어 성능 최적화에 방해가 된다. (useMemo를 사용하거나 상태값/액션을 나눌 수 있지만 좋은 구조는 아니다)
- Context 추가할 때마다 Provider 로 매번 감싸줘야하기 때문에 Provider hell 을 야기할 수 있다.
d. 이럴 때 사용하세요
- low-freqeuncy, 즉 낮은 빈도로 상태값이 변경할 때.
- 로그인 정보 또는 웹사이트 내에 사용자 설정 파일, 테마, 언어, 모달(Modal), 알림창(Alert) 등 상태값이 자주 바뀌지 않는 경우, 컴포넌트 간 간단한 공유 데이터에 사용됩니다.
- 즉 Child Component가 많지 않을 때 사용하는 것을 추천한다