더 깔끔한 API를 위한 TypeScript 팁

좋은 타입은 컴파일러를 만족시키는 것이 아닙니다. 낡지 않는 문서이자, 키를 누를 때마다 실행되는 테스트입니다. 세 가지 기능이 대부분의 일을 해냅니다.

잘못된 상태를 표현 불가능하게

로딩 플래그, 에러 문자열, 데이터 객체를 별도 필드 세 개로 두면 불가능한 조합(로딩이면서 동시에 에러)을 초래합니다. 대신 결과를 구별된 유니온으로 모델링하세요.

type Result =
  | { status: 'loading' }
  | { status: 'error'; message: string }
  | { status: 'success'; data: User };

이제 컴파일러가 모든 경우를 처리하도록 강제하고, status가 'success'가 되기 전에는 data가 아예 존재하지 않습니다.

애너테이션 대신 satisfies

설정에 : Config를 붙이면 타입이 넓어지고 리터럴 추론을 잃습니다. satisfies Config를 쓰면 형태를 검증하면서도 정확한 리터럴 타입을 유지합니다.

이름에는 템플릿 리터럴 타입

라우트 경로, 이벤트 이름, 기능 플래그는 그저 문자열입니다 — 오타가 배포되기 전까지는요. 템플릿 리터럴 타입으로 검증되는 값으로 만드세요.

type Event = `user:${'login' | 'logout' | 'signup'}`;

올바른 코드를 설명하는 타입이 아니라, 잘못된 코드가 컴파일되지 않게 하는 타입을 목표로 하세요.