TypeScript Frontend

프론트엔드 타입 계약이 지키는 화면-API 경계

프론트엔드 애플리케이션은 route, API client, server state, form schema, UI state가 서로 다른 변경 이유를 갖도록 나뉘어야 한다.

01

페이지 경계

라우트 단위에서 필요한 데이터와 권한을 정의하고 하위 컴포넌트로 명확히 전달한다.

페이지 계약
02

API 클라이언트

fetch 호출을 흩뿌리지 않고 요청 DTO, 응답 DTO, 오류 변환을 한곳에 둔다.

client layer
03

상태 분리

서버에서 온 데이터와 입력 중인 폼 상태, 모달 상태를 서로 섞지 않는다.

state kind
04

검증 연결

폼 schema와 API schema를 맞춰 입력 오류와 서버 오류를 같은 UX로 처리한다.

validation
Server state
캐시, 재요청, 동기화가 필요한 데이터는 전용 도구나 fetch 정책으로 관리한다. 로컬 state에 복사하면 stale 데이터가 생기기 쉽다.
cache owner
Form state
사용자가 입력 중인 값은 제출 전까지 별도 상태와 검증 규칙을 가진다. Zod, React Hook Form 같은 조합이 타입과 UX를 연결한다.
입력 계약
Error
네트워크 오류, 검증 오류, 권한 오류를 UI에서 구분한다. 모든 실패를 toast 하나로 처리하면 복구 경로가 사라진다.
recovery

화면-API 경계 점검

DTO 위치 응답 타입이 컴포넌트 내부에 흩어져 있지 않다.
검증 외부 입력은 TypeScript 타입 외에 런타임 schema로 확인한다.
로딩 UX loading, empty, error, success 상태가 서로 다른 화면을 가진다.

상태 분류

server: userQuery.data
form: draftProfile
ui: isModalOpen
url: searchParams.get("tab")