28. 유효한 상태만 표현하는 타입을 지향하기

28-1. 유효한 상태와 무효한 상태를 둘 다 표현

• 예시

28-2. 유효한 상태만 표현

• 예시

29. 사용할 때는 너그럽게, 생성할 때는 엄격하게

• (기본개념) declare 키워드란?
• (기본개념) Pick Omit 제네릭이란?

29-1. 매개변수 타입(사용)은 넓은 범위, 반환 타입(생성)은 좁은 범위여야 한다.

30. 문서에 타입 정보를 쓰지 않기

30-1. 주석에 타입 정보를 적지 않는다.

• 특정 매개변수를 설명 → JSDoc의 @param 구문 사용하기
• 값을 변경하지 않음을 설명 → readonly 사용하기

30-2. 변수명에 타입 정보를 넣지 않는다.

• 예시
• 단위가 있는 숫자들은 예외!
  • 예시

31. 타입 주변에 null값 배치하기

31-1. 한 값의 null 여부가 다른 값의 null 여부와 암시적 연관이 있으면 안된다.

31-2. API 작성 시에는 반환 타입이 null 이거나 null 이 아니도록 만들기

• null과 null이 아닌 값을 섞어서 사용하는 것을 피하기
• 반환 타입을 큰 객체로 만들고 반환 타입 전체가 null 이거나 null 이 아니도록 만들기
• 예시

31-3. 클래스 생성 시 필요한 값이 준비되었을 때 생성하여 null 이 존재하지 않도록 하기

32. 유니온의 인터페이스보다는 인터페이스의 유니온을 사용하기

32-1. 인터페이스의 유니온 사용하기

• 유니온 타입 여러개를 속성으로 가지는 인터페이스의 문제점 → 각 속성이 일관된 조합이 아닐 수 있다
  • 예시
• 인터페이스의 유니온 사용하기
  • 예시

32-2. 타입에 태그 넣기

• 타입에 태그를 넣으면 런타임에 어떤 타입이 사용되는지 판단할 수 있다
• 타입스크립트가 제어 흐름을 분석할 수 있도록 태그된 유니온 고려하기
• 여러 개의 선택적 필드가 동시에 값 존재 / 동시에 undefined인 경우에도 태그된 유니온이 유리하다
  • 예시
• 단, 타입의 구조를 손 댈 수 없는 상황 (API 결과) 에는 인터페이스의 유니온 사용하기
  • 예시

33. string 타입보다 더 구체적인 타입 사용하기