State Sharing

상태 공유는 소유자와 읽기·쓰기 위치부터 정한다

전역 상태 도구를 고르기 전에, 값이 어디에서 만들어지고 어디에서 읽히며 어디에서 변경 요청이 생기는지 표시합니다. 가장 가까운 충분한 범위가 기본 해법입니다.

소유자 읽는 곳과 바꾸는 곳을 모두 포함하는 가까운 부모

읽기 props로 내려받아 화면을 그리는 컴포넌트

쓰기 callback으로 변경 의도만 올리는 컴포넌트

판정 축	확인할 질문	기본 선택	도구 검토 신호
상태 소유자 값의 원본을 들고 있는 컴포넌트	읽는 컴포넌트와 바꾸는 컴포넌트를 모두 포함하는가?	가장 가까운 공통 부모에 `useState`를 둔다.	여러 화면과 라우트가 같은 값을 공유하면 범위를 넓힌다.
읽는 컴포넌트 값을 화면에 쓰는 위치	이 컴포넌트가 값을 변경하지 않고 표시만 하는가?	필요한 값만 props로 내려준다.	중간 컴포넌트가 props를 전달만 하면 Context 후보가 된다.
바꾸는 컴포넌트 사용자 이벤트 발생 위치	자식이 원본 state를 직접 복사하지 않는가?	`onChange(next)`처럼 의도만 부모로 올린다.	업데이트 규칙이 여러 곳에 흩어지면 reducer나 store를 검토한다.
렌더 비용 공유 범위가 넓어진 뒤 생기는 영향	값 변경이 불필요한 하위 트리까지 다시 그리게 하는가?	먼저 상태 범위를 줄이고, 그 다음 memo를 측정한다.	데이터 변경 빈도가 높고 소비자가 많으면 전용 상태 관리를 본다.

값 전달 부모가 값을 계산하고 자식은 읽는다

Dashboard
state: selectedTeam, filter
props: Summary, CardList에 필요한 값만 전달

변경 요청 자식은 변경 의도만 부모에게 알린다

FilterToolbar
event: 사용자가 필터 선택
callback: onFilterChange(nextFilter)

Lift Up 형제가 함께 읽으면 공통 부모로 올린다

같은 화면 안의 여러 컴포넌트가 같은 값을 읽고 바꾸면, 먼저 가장 가까운 공통 부모에 상태를 둡니다.

Context 전달만 하는 중간 단계가 길면 검토한다

중간 컴포넌트가 값을 사용하지 않고 계속 넘기기만 하면 Context나 상태 관리 라이브러리를 검토할 신호입니다.