🎯 학습 목표
- 현재 Todo 앱의 상태 흐름을 구조적으로 이해한다.
- 상태를 전달하는 방법 (props vs context)을 시각적으로 비교한다.
- 앱 규모가 커질수록 어떤 방식이 유지보수에 유리한지 인식한다.
🧱 1. 초기 구조 (props 기반)
초기에는 상태가 상위 컴포넌트(App
)에만 있고, 하위 컴포넌트로 props
를 계속 전달했습니다.
App
├── TodoForm ← text, setText, handleAdd
└── TodoList ← todos, handleToggle, handleDelete
└── TodoItem ← todo, onToggle, onDelete
⚠️ 문제점
- 컴포넌트가 많아질수록
props
가 깊게 전달됨 - 중간 컴포넌트에서 필요 없는 props도 계속 받아야 함
- 재사용성 ↓, 가독성 ↓, 유지보수 비용 ↑
🌐 2. 개선 구조 (Context 기반)
TodoProvider
를 루트에서 감싸고, 내부 컴포넌트는 useTodoContext()
훅으로 상태를 직접 가져옵니다.
TodoProvider (상태 전역 공급)
└── App
├── TodoForm ← context에서 상태 직접 사용
├── TodoList
│ └── TodoItem ← context에서 직접 접근
✅ 장점
항목 | 효과 |
---|---|
전역 공유 | 어디서든 상태 사용 가능 (단, Provider 하위여야 함) |
props 제거 | 컴포넌트 간 불필요한 연결 끊어짐 |
재사용성↑ | 컴포넌트의 역할이 명확해짐 |
유지보수 쉬움 | 상태 위치가 일관되고 예측 가능함 |
💡 상태 관리 요약 비교
기준 | props 기반 | context 기반 |
---|---|---|
상태 전달 | 수동으로 직접 전달 | 전역으로 자동 공유 |
컴포넌트 계층 깊이 | 깊을수록 복잡 | 관계없이 간결 |
재사용성 | 낮음 | 높음 |
적합한 규모 | 소형 앱 | 중대형 앱 이상 |
📌 Tip: Context는 언제 도입할까?
- 상태를 2단계 이상 전달해야 한다면 Context 도입을 고민하세요.
- 특히, 로그인 상태, 테마 상태, 언어 설정처럼 전역에서 공통으로 사용하는 상태에 적합합니다.
💬 댓글
※ 로그인 후 댓글을 작성할 수 있습니다.