아이템31. 타입 주변에 null값 배치하기
한 값의 null 여부가 다른 값의 null 여부에 암시적으로 관련되도록 설계하면 안된다.
ex. b가 a의 값을 바라보고 있고, a가 null이 될 수 있을 때.
API 작성 시에는 반환 타입을 큰 객체로 만들고 반환 타입 전체가 null이거나 null이 아니게 만들어야 한다.
클래스를 만들 때는 필요한 모든 값이 준비되었을 때 생성하여 null이 존재하지 않도록 하는 것이 좋다.
strictNullChecks를 설정하면 코드에 많은 오류가 표시되지만, null값과 관련된 문제점을 찾을 수 있어 반드시 필요하다.
아이템32. 유니온의 인터페이스보다는 인터페이스의 유니온을 사용하기
interface Layer {
layout: FillLayout | LineLayout | PointLayout;
paint : FillPaint | LinePaint | PointPaint;
}위의 코드에서 layout이 FillLayout이면서 paint 속성이 LinePaint일 수는 없다.
따라서 아래와 같이 수정하는 것이 좋다.
interface FillLayer {
layout: FillLayout;
paint : FillPaint;
}
interface LineLayer {
layout: LineLayout;
paint : LinePaint;
}
interface PointLayer {
layout: PointLayout;
paint : PointPaint;
}
type Layer = FillLayer | LineLayer | PointLayer;유니온 타입의 속성을 여러 개 가지는 인터페이스에서는 속성 간의 관계가 분명하지 않기 때문에 실수가 자주 발생하므로 주의해야 한다.
유니온의 인터페이스보다 인터페이스의 유니온이 더 정확하고 타입스크립트가 이해하기 좋다.
타입스크립트가 제어 흐름을 분석할 수 있도록 타입에 태그를 넣는 것을 고려해야 한다. 태그된 유니온은 타입스크립트와 매우 잘 맞아 자주 볼 수 있는 패턴이다.
interface Person {
name : string;
placeOfBirth?: string;
dateOfBirth?: string;
}
interface Person {
name : string;
birth?: {
place: string;
date: Date;
}
}아이템33. string 타입보다 더 구체적인 타입 사용하기
문자열을 남발하여 선언된 코드를 피해야 한다. 좀 더 구체적인 타입을 사용해야 한다.
변수의 범위를 보다 정확하게 표현하고 싶다면 string 보다는 문자열 리터럴 타입의 유니온을 사용해야 한다.
객체의 속성 이름을 함수 매개변수로 받을때는 string보다 keyof T를 사용하는 게 좋다.
아이템34. 부정확한 타입보다는 미완성 타입을 사용하기
타입 안전성에서 불쾌한 골짜기는 피해야 한다. 타입이 없는 것보다 잘못된 게 더 나쁘다.
타입 선언에서 어설프게 완벽을 추구하려다가 오히려 역효과가 발생하는 것을 주의하자.
타입 정보를 구체적으로 만들수록 오류 메시지와 자동 완성 기능에 주의를 기울여야 한다. 정확도뿐만 아니라 개발 경험과도 관련된다.
아이템35. 데이터가 아닌, API와 명세를 보고 타입 만들기
코드의 구석 구석까지 타입 안전성을 얻기 위해 API 또는 데이터 형식에 대한 타입 생성을 고려해야 한다.
데이터에 드러나지 않는 예외적인 경우들이 문제가 될 수 있기 때문에 명세로부터 코드를 생성하는 게 좋다.
frontend-react