출처 구분
사용자가 만든 상태인지, 서버 응답인지, 브라우저 URL인지 먼저 분류한다.
서버 데이터를 클라이언트 전역 상태에 복사하면 동기화 문제가 생긴다
원본 위치
UI 입력이면 local, 서버 응답이면 cache가 먼저다.
구독 범위
한 영역이면 props/useState, 여러 화면이면 store 후보로
올린다.
수명
URL·세션·페이지 이동 후에도 남아야 하는지로 저장 위치를
좁힌다.
도구 비용
time travel, middleware가 필요할 때만 Redux급 구조를
선택한다.
수명 확인
컴포넌트가 사라지면 버려도 되는지, 페이지 이동 후에도 남아야 하는지 판단한다.
수명보다 넓게 저장하면 오래된 값이 남는다구독 범위
누가 읽고 누가 쓰는지 표시해 props, context, store 중 가장 좁은 방식을 고른다.
전역은 마지막 선택에 가깝다서버 캐시 분리
fetch 결과, loading, error, refetch, invalidation은 Query 계열 도구가 맞는지 검토한다.
캐시 무효화는 상태 변경보다 데이터 계약에 가깝다디버깅 요구
action history, time travel, middleware가 필요한 복잡한 흐름인지 확인한다.
도구 비용과 팀 숙련도를 같이 본다useState
가까운 UI 상태
입력값, 열림 여부, 현재 탭처럼 한 영역에 닫힌 상태에
적합하다.
가장 먼저 고려한다
Context
낮은 빈도 공유
theme, locale, auth summary처럼 여러 곳에서 읽지만 자주 바뀌지
않는 값에 좋다.
value identity를 관리한다
Zustand
가벼운 클라이언트 store
여러 화면이 읽고 쓰지만 Redux 수준의 action 구조가 과한 경우에
맞다.
selector를 좁게 쓴다
Query
서버 상태 캐시
fetch, stale time, refetch, mutation invalidation을
관리한다.
원본은 서버라는 사실을 유지한다