item 28
- 유효한 상태만 표현하는 타입을 지정하자.
- 유효한 상태를 표현하는 값만 허용한다면 코드를 작성하기 쉬워지고 타입 체크가 용이해짐.
item 29
- 매개 변수 타입은 느슨하게, 반환 타입은 엄격하게 하자.
item 30
- 주석, 변수명에 타입을 적지말자.
ageNum
보다age:number
를 사용하듯이.- 코드는 바꾼 채 주석을 안바꾸는 등 타입 정보에 모순이 발생할 수 있음.
- 단위가 있는 숫자는 예외임. ex) temperatureC
item 31
- strickNullChecks를 사용하자.
- null 값이 암시적으로 관련되도록 설계하지 말자.
- api 작성 시 반환 타입을 큰 객체로 만들고 반환 타입 전체가 null이거나 null이 아니게 만들어야 함.
item 32
- 타입끼리의 충돌이 일어날 경우 각각 타입의 계층을 분리된 인터페이스로 둬야 함.
item 33
- 모든 문자열을 할당할 수 있는 string 타입보다는 더 구체적인 타입을 사용하자.
- 객체의 속성 이름을 함수 매개변수로 받을 때 string 보다 keyof T를 사용하자.
item 34
- 부정확한 타입보다 미완성 타입 사용하기.
- 정의가 어렵다면 any와 unknown 구별해서 타입을 지정하자.
item 35
- 라이브러리 쓸 때 @types/~~ 를 통해 타입을 추가할 수 있음.
- grpahQL을 쓴다면 자체적으로 타입을 생성할 수 있음. Apollo로 타입스크립트 타입으로 변환도 가능.
- p.191쪽 하단 예시 잘못됐나? 파리미터 g가 쓰이지 않음.
item 36
- 타입 변수명 잘 짓자.
item 37
_brand
로 상표를 붙일 수 있음.