Context 경계

Context 구독 범위

Context API는 여러 컴포넌트가 같은 값을 읽게 해주지만, Provider value가 바뀌면 그 값을 읽는 하위 트리가 함께 다시 렌더링된다. 전역 저장소처럼 쓰기보다 어떤 값이 얼마나 자주 바뀌는지와 어느 범위가 구독해야 하는지를 먼저 정해야 한다.

Provider Value theme · auth · locale Consumer A 실제로 값을 읽는 컴포넌트 Stable Area props/composition 분리 Hot Value state · input 변화
01

공유 필요 확인

두세 단계 props 전달인지, 여러 갈래 하위 트리에서 같은 값을 읽어야 하는지 구분한다.

단순 전달은 composition이 더 선명할 수 있다
02

Provider 위치 선택

앱 전체, 레이아웃, 기능 영역 중 값이 실제 필요한 가장 좁은 위치에 둔다.

Provider가 넓을수록 영향 범위도 넓어진다
03

값 모양 고정

state, dispatch, derived value를 한 객체에 섞을지 나눌지 결정한다.

자주 바뀌는 값과 거의 안 바뀌는 값을 분리한다
04

identity 관리

객체와 함수 value는 useMemo, useCallback 또는 reducer dispatch로 불필요한 변경을 줄인다.

새 객체를 매 렌더 만들면 consumer도 흔들린다
05

성능 확인

React DevTools Profiler로 Provider 변경 때 어떤 consumer가 다시 렌더링되는지 본다.

느린 화면은 context 자체보다 구독 범위에서 생긴다
Theme
거의 모든 곳에서 읽는 값 변경 빈도가 낮고 많은 컴포넌트가 읽어야 하므로 Context에 잘 맞는다.
색상 토큰 객체 identity를 안정화한다
Form State
자주 바뀌는 입력값 키 입력마다 하위 전체가 흔들릴 수 있어 좁은 Provider나 폼 전용 store를 검토한다.
입력 성능을 실제로 측정한다
Auth
사용자와 권한 정보 로그인 상태, 권한, refresh 상태를 분리해 필요한 컴포넌트만 읽게 한다.
토큰 원문은 노출 범위를 좁힌다
Dispatch
안정적인 함수 전달 useReducer의 dispatch는 identity가 안정적이라 상태값과 분리하기 좋다.
읽기와 쓰기 context를 나눌 수 있다

구현 확인

구독 범위 Provider를 한 단계 아래로 내려도 동작하는지 확인한다.
렌더 횟수 value 변경 시 실제로 필요한 consumer만 다시 그려지는지 profiler로 본다.
대안 비교 props composition이나 상태 라이브러리가 더 명확한 경우인지 검토한다.