프론트엔드
Redux, Again
두줄요약
복잡한 React 상태를 Local State, Context + Hook, Redux로 나누어 관리한 경험을 공유했습니다. Redux의 보일러플레이트보다 상태 추적과 디버깅이 주는 장기 생산성을 재평가했습니다.
문제 상황
- 부모 페이지의 다수 모달과 늘어나는 체크박스 조건으로
setState기반 상태 관리 복잡도 증가 - 기획 조건 하나의 변경에도 자식 컴포넌트 조건문 수정이 연쇄되는 백오피스 코드
구조와 흐름
- 컴포넌트 내부 상태는 Local State, 여러 컴포넌트에서 필요한 상태는 Redux의 Global State로 분리
- 페이지 내부 관심사는 Context + Hook, 페이지 간 또는 페이지를 넘는 관심사는 Redux로 구분
- HOC·Render Props·Hook을 거쳐 계층 변화 없는 로직 재사용을 위한 Hook 채택
트레이드오프
- HOC와 Render Props의 래핑·중첩 구조 복잡성, 상태·로직 재사용 한계
- Apollo Reactive Variables의 쉬운 전역 접근·변경과 상태 변경 추적 및 유지보수 어려움
- Redux의 보일러플레이트 부담과 상태 변화 순서 통제·공유 상태 추적성의 교환
선택 이유
- Redux Devtools 기반 버그 위치와 상태 변화 순서 추적
- 복잡한 공유 상태에서 기능 추가와 디버깅을 지원하는 장기적 생산성
- Apollo 의존성 및 Reactive Variables 운영 경험 이후 Component Shared State에도 Redux 재선택
