상태
UI에서 동적으로 표현되는 데이터
side effect
함수의 입력 외에도 함수의 결과에 영향을 미치는 요인
예) 네트워크 요청, API 호출
presentation component(표현 컴포넌트)
fetch와 같은 API 요청이 없이도 이 컴포넌트는 작동되어야 합니다
표현(presentation)할 수 있어야 합니다.
하지만,
앱을 만들다보면 분명 API 호출도 해야하고, side effect는 불가피하게 생기기 마련이이죠.
이러한 side effect에 의존적인 상태도 있을 수 있다습니다.
상태의 두 가지 구분
로컬 상태
특정 컴포넌트 안에서만 관리되는 상태
다른 컴포넌트와 데이터를 공유하지 않는 폼(form) 데이터는 대부분 로컬 상태입니다.
input box, select box 등과 같이 입력값을 받는 경우가 이에 해당합니다.
전역 상태
프로덕트 전체 혹은 여러가지 컴포넌트가 동시에 관리하는 상태
장바구니에 담긴 물품의 경우, 상품 선택 여부에 따라 총 주문 금액을 업데이트해야 합니다.
장바구니에 담긴 물품은 그 갯수 등을 다른 컴포넌트에 전달해주어야 합니다.
데이터 로딩 여부(로딩중) 상태 역시, 앱 전반에 영향을 미칩니다.
서로 다른 컴포넌트가 동일한 상태를 다룬다면, 이 출처는 오직 한 곳이어야 합니다.
여기서 '하나의 출처'는 다른 말로, '전역 공간'이라고 볼 수 있습니다.
전역 상태 case
- 네이버를 비롯한 여러 사이트에서 다크모드 기능
- 국제화(globalization) 설정
- undo/redo를 위한 history 기능(포토샵)
데이터 무결성
데이터의 정확성을 보장하기 위해 데이터의 변경이나 수정 시 제한을 두어
안정성을 저해하는 요소를 막고 데이터 상태들을 항상 옳게 유지하는 것
신뢰할 수 있는 단일 출처(single source of truth)
동일한 데이터는 항상 같은 곳에서 데이터를 가지고 온다
데이터 무결성을 위한 방법론
상태 관리 툴
- React Context
- Redux
- MobX
상태 관리 툴 기능
- 전역 상태 저장소 제공
- props drilling(프로퍼티 내려꽂기) 이슈 해결
props drilling(프로퍼티 내려꽂기) 문제
예를 들어, A라는 컴포넌트에 상태가 있고, I라는 컴포넌트가 해당 상태를 사용한다고 하면, 그 중간에 존재하는 C, G 등은 굳이 name이라는 상태가 필요하지 않음에도, 컴포넌트에 props를 만들어 자식 컴포넌트에 넘겨주어야 했습니다.
상태 관리 툴이 반드시 필요할까요?
아닙니다.
상태 관리 툴이 없어도 충분히 규모있는 애플리케이션을 만들 수 있습니다.
Redux의 개발자인 Dan Abramov도 'You Might Not Need Redux'라는 아티클을 통해, React 공식문서의 "React로 사고하기"만 잘 따라와도 대부분의 문제를 해결할 수 있다고 언급합니다.
그러므로 장단점을 분명히 인지하고 상태 관리 툴을 씁시다.
그리고 상태 관리의 기본기라고 볼 수 있는 "상태가 어디에 위치해야 하는지"를 먼저 익힙시다.
