JSON → TypeScript
API 응답을 붙여넣으면 프로젝트에 바로 쓸 수 있는 타입이 나옵니다.
export 붙이기
readonly 붙이기
null은 선택 속성으로
배열 전체 검사
JSON
TypeScript
// Paste JSON on the left
// Paste JSON on the left
실제 API 응답을 그대로 커밋할 수 있는 타입으로 바꿉니다. JSON을 붙여넣으면 중첩된 객체마다 이름 붙은 인터페이스가 나오고, 선택 속성 여부는 추측이 아니라 데이터에서 판단합니다.
응답 샘플을 보고 인터페이스를 손으로 옮기는 일은 단순 작업이지만 함정이 하나 있습니다. 하필 그 샘플에서 null이거나 빠져 있던 필드입니다. 첫 번째 객체만 보는 생성기는 그 필드를 null로 타입 지정하거나 아예 빠뜨리고, 문제는 실제 데이터가 들어온 뒤에 드러납니다.
이 페이지는 배열의 첫 요소가 아니라 모든 요소를 함께 봅니다. 일부에만 있는 필드는 선택 속성이 되고, 어떤 요소에서는 숫자이고 다른 요소에서는 문자열인 필드는 추측 대신 유니온이 됩니다. 중첩 객체는 인라인 형태가 아니라 이름 붙은 인터페이스로 뽑아내므로, 결과를 그대로 프로젝트에 붙여 넣을 수 있습니다.
생성된 인터페이스는 서버와 맺은 계약이 아니라 붙여넣은 샘플에 대한 설명입니다. 이 구분이 결과를 얼마나 믿어도 되는지를 결정합니다. API가 반환할 수 있지만 그 응답에는 마침 나오지 않은 것은 전부 보이지 않습니다. 오류 형태, 관리자에게만 나오는 필드, 여기서는 비어 있지만 운영에서는 객체로 채워지는 배열 같은 것들입니다. 응답 여러 개를 배열로 이어 붙여 샘플을 넓히는 것이 그런 것들을 잡는 가장 싼 방법이고, 이 페이지가 여러 객체를 함께 보고 추론하는 이유이기도 합니다.
결과를 쓰기 전에 숫자는 한 번 더 볼 만합니다. JSON에도 타입스크립트에도 숫자 타입은 하나뿐이라, 정수 식별자와 소수점이 있는 가격이 모두 number 로 타이핑됩니다. 맞는 결과이지만 진짜 문제를 가립니다. 자바스크립트 숫자는 2의 53제곱을 넘으면 정밀도를 잃으므로, 64비트 식별자가 JSON 숫자로 도착하는 순간 타이핑을 하기도 전에 이미 값이 틀어져 있습니다. 이 사실을 아는 API는 그런 식별자를 문자열로 보냅니다. 숫자일 줄 알았던 필드가 string 으로 나왔다면 대개 실수가 아니라 서버가 신중한 것입니다.
날짜도 타입이 정직하지만 도움이 되지는 않는 자리입니다. ISO 형식의 시각은 JSON이 보기에 문자열이므로 string 으로 타이핑되고, 그게 맞습니다. 파서가 돌려주는 것이 문자열이기 때문입니다. 그것을 Date 로 바꿀지는 응답을 소비하는 코드가 내릴 결정이지 생성기가 전제할 일이 아닙니다. 인터페이스에는 브랜드 타입이나 주석으로 표시해 두는 편이, JSON.parse 가 Date 객체를 만들어 주는 척하는 것보다 쓸모 있습니다.
그 키의 모든 샘플이 null이었기 때문입니다. JSON의 null에는 타입 정보가 없어서 그보다 구체적으로 쓰면 추측이 됩니다. 값이 채워진 응답을 붙여넣으면 실제 타입이 나옵니다.
아직은 TypeScript의 interface와 type만 지원합니다. 생성된 구조 자체는 대부분 언어의 모델 클래스에 그대로 대응되므로 직접 옮기기는 어렵지 않습니다.
됩니다. 파싱에 실패하면 JSON 파서의 오류 메시지를 그 자리에 보여주므로 타입을 보기 전에 데이터부터 고칠 수 있습니다.