리액트 공식문서 - LEARN REACT > Managing State 정리

Choosing the State Structure

1. Group related state: 항상 같이 갱신되어야하는 상태가 2개 이상 존재한다면 object, array 등으로 묶어 한꺼번에 관리하는 것을 고려하자.

2. Avoid contracdictions in state: 모순되는 상태 관계를 구축하지 마라. 예를들어 로딩 단계에 대해 isLoading, isDone 로 상태를 2개 두어 관리한다고 해보자. 코드 작성 과정에서 한 개의 상태라도 갱신을 빠트리는 경우, state 간의 모순이 생길 수 있다. 이런 경우는 loadingState(init | loading | done) 처럼 하나의 상태만을 두어 관리하는 것이 안전하다.

3. Avoid redundant state: 불필요한 상태를 두지 말자. 예를들어 이름에 대한 상태를 관리한다고 가정해보자. firstName, secondName, fullName 3개의 상태를 둔다고 가정해보면, 사실상 fullName은 불필요한 상태이다.(firstName, secondName의 조합으로 유추 가능)

4. Avoid duplication in state: 중복되는 상태를 피하자. 중복되는 상태를 활용하게 되는 경우, 작업을 두 번씩 해야하는 경우가 생길 수 있다. 중복의 여지가 있는 경우, 메인 데이터 역할을 하는 상태와 데이터에 대한 힌트를 담당하는 상태 한 개씩을 두어 관리하자.

 

Sharing State Between Components

형제 요소와 연동되어 동작해야하는 컴포넌트가 있다면 공통 부모 컴포넌트로의 lifting stating up을 고려하자.

 

Preserving and Resetting State

state는 컴포넌트에 귀속되지 않는다. React가 DOM 트리 구조를 기반해서 state를 매 렌더링마다 주입시키는 것이다. 그래서 DOM 구조를 유지하고 동일한 컴포넌트를 렌더링하게 된다면 state가 reset 되지 않는 것이다. 하지만 key를 다르게 준다면 rerendering 과정에서 state가 reset된다.(key는 parent 내로 중복 범위가 한정된다.)

 

Extracting State Logic Into a Reducer

리듀서를 활용해서 컴포넌트로부터 비즈니스 로직을 분리시킬 수 있다. 이벤트 핸들러를 호출시킬 때도 eventName과 payload를 토대로 dispatch하는 부분만 작성되므로 무엇을 하는 코드인지만 남길 수 있어 코드의 의미도 더욱 명확하게 바꿀 수 있다. 코드가 장황해질 수 있다는 점이 단점

*useReducer 이름의 유래: 배열 메소드의 reduce 함수는 요소들을 순회해서 전달한 reducer 함수의 결과로 변환한다. useReducer도 변환함수 reducer와 초기 상태 값을 토대로 새로운 상태 값을 뽑아낸다는 점에서 reduce 함수의 동작 방식을 차용한 네이밍이라고 한다.

 

Passing Data Deeply with Context & Scaling Up with Reducer and Context: 생략