이펙티브 타입스크립트 4장

4장 타입설계

아이템 28 - 유효한 상태만 표현하는 타입을 지향하기

타입을 설계할 때 값들을 포함하거나 제외할지 신중하게 생각해야 한다.
유효한 상태만 표현해야 코드 작성이 쉬워지고 타입 체크가 용이해진다.

값이 error 이거나 true, false 인지 알 수 없을 상황을 고려해야한다.

아이템 29 - 사용할 때는 너그럽게, 생성할 때는 엄격하게

함수의 매개변수는 타입의 범위가 넓어도 되지만, 결과 반환 시 타입의 범위가 구체적이어야 한다.
사용하기 편한 API일수록 반환 타입이 엄격하다.

아이템 30 - 문서에 타입 정보를 쓰지 않기

주석과 코드가 제대로 동기화 되지 않다면 차라리 주석을 지워버리자.
타입 구문은 타입 체커가 타입 정보를 동기화하기 때문에 코드가 변경되더라도 정보가 정확히 동기화가 된다.
타입이 명확하지 않다면 단위 정보를 포함하는것도 나쁘지 않다.

아이템 31 - 타입 주변에 null 값 배치하기

strictNullChecks 옵션을 설정하면 null이나 undefined에 대해 오류들이 나타날 수 있다.
null이거나 아닌 경우의 상태를 고려해야 한다.

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

유니온의 인터페이스

interface Layer {
  layout: FillLayout | LineLayout | PointLayout;
  paint: FillPaint | LinePaint | PointPaint;
}

인터페이스의 유니온

interface FillLayer {
  layout: FillLayout;
  paint: FillPaint;
}
interface LineLayer {
  layout: LineLayout;
  paint: LinePaint;
}
interface PointLayer {
  layout: PointLayout;
  paint: PointPaint;
}
type Layer = FillLayer | LineLayer | PointLayer;

아이템 33 - string 타입보다 더 구체적인 타입 사용하기

타입을 설정할 때 일반적인 string을 사용하지 말고 보다 정확하게 타입을 설정하는게 좋다.
예를 들어, 날짜 형식의 값이라면 Date()로, 단 두 개의 값인 유니온 타입이라면
type RecordingType = 'studio' | 'live' 식으로 범위를 줄이는 것이 좋다.

아이템 34 - 부정확한 타입보다는 미완성 타입을 사용하기

타입이 구체적일 수록 버그를 더 잡기 쉽고 타입스크립트가 제공하는 도구를 활용할 수 있다.

타입 정제 시 과도하게 할 경우 오히려 코드가 부정확할 가능성이 있기에 정확하게 모델링 할 수 없다면 차라리 any와 unknown을 구별해서 사용하는것이 좋을 경우가 있다.

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

파일 형식, API, spec을 보고 타입을 생성한다.

아이템 36 - 해당 분야의 용어로 타입 이름 짓기

타입 이름을 지을때 의미없는 Data, Info .. 식으로 설정하지 말고 의미 있게 지어야 한다.

아이템 37 - 공식 명칭에는 상표를 붙이기

구조적 타이핑으로 인해 값을 세밀하게 구분하지 못하는 경우를 위해 brand (상표)를 붙이는 것을 고려해야 한다.
상표 기법은 타입 시스템 내에서 표현할 수 없는 수많은 속성들을 모델링하는데 사용이 된다.