📎아이템 35 데이터가 아닌, API와 명세를 보고 타입 만들기

파일 형식, API, 명세 등 프로젝트 외부에서 가져온 것들은 타입을 직접 작성하지 않고 자동으로 생성할 수 있다. 예시 데이터가 아니라 명세를 참고해 타입을 생성한다는 것이다. (사용자의 실수 줄임) 반면, 예시 데이터를 참고하면 눈 앞의 데이터만 고려하므로 예기치 않은 오류가 발생할 수 있다.

🔗 JSON

GeoJSON 명세를 사용하여 타입스크립트 타입 선언을 사용하자. 직접 작성할 수 있지만 예외 상황이 포함되지 않았고, 완벽하지 않으므로 명세를 기반으로 타입을 작성하여 데이터와 사용 가능한 모든 값에 대해 작동한다는 확신을 갖자.

🔗 API 호출

특히 GraphQL처럼 자체적으로 타입이 정의된 API

GraphQL API는 타입스크립트와 비슷한 타입을 사용하며, 가능한 모든 쿼리와 인터페이스를 명세하는 스키마로 이루어진다. 특정 쿼리에 대한 타입스크립트 타입을 생성할 수 있다.

🔗 명세 정보나 공식 스키마가 없는 경우

데이터로부터 타입을 생성해야 할 때, quicktype 같은 도구를 사용하자. (생성된 타입이 실제 데이터와 일치하지 않을 수 있다는 점을 주의)

✏️ 자동 타입 생성의 이점

브라우저 DOM API에 대한 타입 선언은 공식 인터페이스로부터 생성되었다. 이를 통해 복잡한 시스템을 정확히 모델링하고 타입스크립트가 오류나 코드상의 의도치 않은 실수를 잡을 수 있게 한다.

📍 요약

• 코드의 모든 곳에서까지 타입 안정성을 얻기 위해 API 또는 데이터 형식에 대한 타입 생성을 고려해야 한다.

• 데이터에 드러나지 않는 예외적인 경우들이 문제가 될 수 있으므로 데이터보다는 명세로부터 코드를 생성하는 것이 좋다.