"문법 이름을 아는 데서 멈추지 말고, 실제 프런트엔드에서 그 문법이 맡은 일을 찾아봐."
다섯 경계로 한 앱 읽기
타입이 제대로 붙은 React 프런트엔드를 처음 열면 파일 수에 압도되기 쉬워. 전부 순서대로 읽지 말고 공유 타입, API, 상태 훅, 상위 조립, 말단 UI라는 다섯 경계를 따라가. 각 경계에서 입력이 무엇이고 출력이 무엇인지 적으면 시스템의 뼈대가 보여.
첫째, 공유 타입
src/types/나 핵심 도메인 파일에서 시작해. 메시지 역할 같은 리터럴 합집합, 대화와 메시지의 레코드 모양, 스트리밍 이벤트의 판별 합집합을 찾아. 선택적 필드가 정말 선택 상태인지, 여러 상태를 한 객체에 우겨 넣은 흔적인지도 봐.
둘째, 외부 API 경계
lib/api.ts 같은 파일에서 Promise<T>의 T가 어디서 왔는지 추적해. 응답 JSON을 단언만 하는지 런타임에서 검증하는지, catch의 unknown을 어떻게 좁히는지, 타입 전용 import가 실행 의존성과 분리되어 있는지 확인해.
셋째, 상태와 이벤트
커스텀 훅이나 reducer에서 서버 이벤트가 UI 상태로 바뀌는 과정을 따라가. action 합집합의 판별 필드, 모든 경우를 빠짐없이 처리하는 switch, 로딩·성공·실패 상태가 가능한 조합만 허용하는지 살펴. 제네릭이 입력과 출력의 관계를 보존하는 자리도 표시해 봐.
넷째와 다섯째, 조립과 렌더
App.tsx 같은 상위 컴포넌트에서는 상태 소유권과 영역 사이 콜백을 보고, 작은 말단 컴포넌트에서는 props가 DOM 이벤트와 JSX로 이어지는 길을 봐. 상위가 모든 세부를 알거나 말단 컴포넌트가 직접 전역 상태를 건드린다면 경계가 흐린 신호일 수 있어.
읽은 뒤 설명해 보기
- 각 판별 합집합이 어떤 상태나 이벤트를 닫아 두는가?
- 각
Promise<T>의T는 어디에서 검증되는가? - 타입 좁히기는 어느 조건에서 일어나며 실패 경로는 어디로 가는가?
- 값 import와
import type의 차이가 실행 그래프에 어떤 영향을 주는가?
실전 읽기의 시험은 파일을 다 본 것이 아니라 데이터 한 조각의 왕복을 설명할 수 있는지야. 불투명한 경계가 보이면 그곳이 다시 펼칠 레슨이야.