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

strictNullChecks 설정을 처음 켜면, null이나 undefined 값 관련된 오류들이 갑자기 나타나기 때문에 오류를 걸러내는 if구문을 코드 전체에 추가해야 한다고 생각할 수 있다.

왜냐하면 어떤 변수가 null이 될 수 있는지 없는지를 타입만으로는 명확하게 표현하기 어렵기 때문이다.

값이 전부 null이거나 전부 null이 아닌 경우로 분명히 구분된다면, 값이 섞여있을 때보다 다루기 쉽다. 타입에 null을 추가하는 방식으로 이러한 경우를 모델링할 수 있다.

// tsConfig: {"strictNullChecks":false}  
  
function extent(nums: number[]) {  
  let min, max  
  for (const num of nums) {  
    if (!min) {  
      min = num  
      max = num  
    } else {  
      min = Math.min(min, num)  
      max = Math.max(max, num)  
    }  }  
  return [min, max]  
}

undefined를 포함하는 객체는 다루기 어렵고 절대 권장하지 않는다. 코드를 살펴보면 min과 max가 동시에 둘 다 undefined이거나 둘 다 undefined가 아니라는 것을 알 수 있지만, 이러한 정보는 타입시스템에서 표현할 수 없다.

// tsConfig: {"strictNullChecks":true}  
function extent(nums: number[]) {  
  let min, max  
  for (const num of nums) {  
    if (!min) {  
      min = num  
      max = num  
    } else {  
      min = Math.min(min, num)  
      max = Math.max(max, num)  
      // ~~~ Argument of type 'number | undefined' is not  
      //     assignable to parameter of type 'number'    }  
  }  
  return [min, max]  
}

extent의 반환 타입이 (null | undefined)[]로 추론되어서 설계적 결함이 분명해졌다. 이제는 extent를 호출하는 곳마다 타입 오류의 형태로 나타난다.

한 값의 null 여부가 다른 값의 null 여부에 암시적으로 관련되도록 설계하면 안된다.

더 나은 해법은 min과 max를 한 객체 안에 넣고 null이거나 null이 아니게 하면 된다.

function extent(nums: number[]) {  
  let result: [number, number] | null = null  
  for (const num of nums) {  
    if (!result) {  
      result = [num, num]  
    } else {  
      result = [Math.min(num, result[0]), Math.max(num, result[1])]  
    }  
  }  
  return result  
}

이제는 반환 타입이 [number, number] | null이 되어서 사용하기가 더 수월해졌다.

const [min, max] = extent([0, 1, 2])!  
const span = max - min // OK

null 아님 대신 단순 if 구문으로도 체크할 수도 있다.

const range = extent([0, 1, 2])  
if (range) {  
  const [min, max] = range  
  const span = max - min // OK  
}

extent의 결과값으로 단일 객체를 사용함으로써 설계를 개선했고, 타입스크립트가 Null 값 사이의 관계를 이해할 수 있도록 했으며 버그도 제거했다.

API 작성 시에는 반환 타입을 큰 객체로 만들고 반환 타입 전체가 null 이거나 null이 아니게 만들어야 한다. 사람과 타입 체커 모두에게 명료한 코드가 될 것이다.

클래스를 만들 때는 필요한 모든 값이 준비되었을 때 생성하여 Null 이 존재하지 않도록 하는 것이 좋다.

strictNullChecks를 설정하면 코드에 많은 오류가 표시되겠지만, null 값과 관련된 문제점을 찾아낼 수 있기 때문에 반드시 필요하다.

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

유니온 타입의 속성을 여러 개 가지는 인터페이스에서는 속성 간의 관계가 분명하지 않기 때문에 실수가 자주 발생하므로 주의해야 한다.

유니온의 인터페이스보다 인터페이스의 유니온이 더 정확하고 타입스크립트가 이해하기도 좋다.

벡터를 그리는 프로그램을 작성중이고, 기하학적타입을 가지는 계층의 인터페이스를 정의한다고 가정해보자.

type FillPaint = unknown  
type LinePaint = unknown  
type PointPaint = unknown  
type FillLayout = unknown  
type LineLayout = unknown  
type PointLayout = unknown  

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

타입스크립트가 제어 흐름을 분석할 수 있도록 타입에 태그를 넣는 것을 고려해야 한다. 태그된 유니온은 타입스크립트와 매우 잘 맞기 때문에 자주 볼 수 있는 패턴이다.

또 다른 예시는 태그된 유니온을 예로 들 수 있다.

interface Layer {  
  type: 'fill' | 'line' | 'point'  
  layout: FillLayout | LineLayout | PointLayout  
  paint: FillPaint | LinePaint | PointPaint  
}

type: 'fill' 과 함께 LineLaouy과 PointPaint 타입이 쓰이는 것은 말이 되지 않는다. 이러한 경우를 방지하기 위해 Layer를 인터페이스의 유니온으로 변환해보자.

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

type Layer = FillLayer | LineLayer | PointLayer  
function drawLayer(layer: Layer) {  
  if (layer.type === 'fill') {  
    const { paint } = layer // Type is FillPaint  
    const { layout } = layer // Type is FillLayout  
  } else if (layer.type === 'line') {  
    const { paint } = layer // Type is LinePaint  
    const { layout } = layer // Type is LineLayout  
  } else {  
    const { paint } = layer // Type is PointPaint  
    const { layout } = layer // Type is PointLayout  
  }  
}

각 타입의 속성들 간의 관계를 제대로 모델링하면 타입스크립트가 코드의 정확성을 체크하는 데 도움이 된다. 다만 타입 분기 후 layer가 포함된 동일한 코드가 반복되는 것이 어수선해 보인다.

태그된 유니온은 타입스크립트와 매우 잘 맞기때문에 필요할 때 적용하도록하자.

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

'문자열을 남발하여 선언된' 코드를 피하도록하자. 모든 문자열을 할당할 수 있는 string 타입보다는 더 구체적인 타입을 사용하는 것이 좋다.

string 타입의 범위는 매우 넓다.

interface Album {  
  artist: string  
  title: string  
  releaseDate: string // YYYY-MM-DD  
  recordingType: string // E.g., "live" or "studio"  
}  

변수의 범위를 보다 정확하게 표현하고 싶다면 string 타입보다는 문자열 리터럴 타입의 유니온을 사용하면 된다. 타입 체커를 더 엄격히 할 수 있고 생산성을 향상시킬 수 있다.

releaseDate 필드는 Date 객체로 사용해서 날짜 형식으로만 제한하는것이 좋다. recordingType 필드는 'live'와 'studio' 단 두 개의 값으로 유니온 타입을 정의할 수 있다.

type RecordingType = 'studio' | 'live'  
  
interface Album {  
  artist: string  
  title: string  
  releaseDate: Date  
  recordingType: RecordingType  
}

객체의 속성 이름을 함수 매개변수로 받을 때는 string보다 keyof T를 사용하는 것이 좋다.

function pluck<T, K extends keyof T>(record: T[], key: K): T[K][] {  
  return record.map(r => r[key])  
}

pluck(albums, 'releaseDate') // Type is Date[]  
pluck(albums, 'artist') // Type is string[]  
pluck(albums, 'recordingType') // Type is RecordingType[]  
pluck(albums, 'recordingDate')  
// ~~~~~~~~~~~~~~~ Argument of type '"recordingDate"' is not  
//                 assignable to parameter of type ...

이와같이 keyof T 부분집합을 활용하여 객체의 속성을 제대로 반환타입이 추론될 수 있다.

보다 정확한 타입을 사용하면 오류를 방지하고 코드의 가독성도 향상시킬 수 있다.

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

타입 안전성에서 불쾌한 골짜기는 피해야한다. 타입이 없는 것보다 잘못된게 더 나쁘다.

불쾌한 골짜기

로봇 공학과 인공 지능에서 많이 쓰이는 용어 어설프게 인간과 비슷한 로봇에서 느끼는 불쾌함을 뜻한다. 저자의 의도는 타입 선언에서 어설프게 완벽을 추구하려다가 오히려 역효과가 발생하는 것을 주의하자는 의미이다.

타입 선언을 작성하다 보면 코드의 동작을 더 구체적으로 또는 덜 구체적으로 모델링하게 되는 상황을 맞닥뜨리게 된다.

일반적으로 타입이 구체적일수록 버그를 더 많이 잡고 타입스크립트가 제공하는 도구를 활용할 수 있게 된다.

그러나 타입 선언의 정밀도를 높이는 일에는 주의를 기울여야 한다.

예를들어 다음의 GeoJSON은 각각 다른 형태의 좌표 배열을 가지는 타입이다.

interface Point {  
  type: 'Point'  
  coordinates: number[]  
}  
interface LineString {  
  type: 'LineString'  
  coordinates: number[][]  
}  
interface Polygon {  
  type: 'Polygon'  
  coordinates: number[][][]  
}  
type Geometry = Point | LineString | Polygon // 다른 것들도 추가될 수 있다.

큰 문제는 없지만 좌표에 쓰이는 number[]가 약간 추상적이다. 여기서 number[]는 경도와 위도를 나타내므로 튜플 타입으로 선언하는게 낫다.

type GeoPosition = [number, number]  
interface Point {  
  type: 'Point'  
  coordinates: GeoPosition  
}  
// Etc.

타입을 더 구체적으로 개선했기 때문에 더 나은 코드가 된 것 같다.

커뮤니티에 자랑하여 좋아요를 기대했지만 안타깝게도 새로운 코드가 빌드를 깨뜨린다며 불평하는 사용자들의 모습만 보게 될 것이다.

코드에는 위도와 경도만을 명시했지만, GeoJSON의 위치 정보에는 세번째 요소인 고도가 있을 수도 있고 또 다른 정보가 있을 수도 있다.

결과적으로 타입 선언을 세밀하게 만들고자 했지만 시도가 너무 과했고 오히려 타입이 부정확해졌다.

정확하게 타입을 모델링할 수 없다면 부정확하게 모델링하지 말아야 한다. 또한 any와 unknown를 구별해서 사용해야 한다.

타입 정보를 구체적으로 만들수록 오류 메시지와 자동완성 기능에 주의를 기울여야 한다. 정확도뿐만 아니라 개발 경험과도 관련된다.

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

코드의 구석 구석까지 타입 안정성을 얻기 위해 API 또는 데이터 형식에 대한 타입 생성을 고려해야 한다.

데이터에 드러나지 않는 예외적인 경우들이 문제가 될 수 있기 때문에 데이터보다는 명세로부터 코드를 생성하는 것이 좋다.

파일형식, API, 명세 등 우리가 다루는 타입 중 최소한 몇 개는 프로젝트 외부에서 비롯된다. 이러한 경우에는 타입을 직접 장성하지 않고 자동으로 생성할 수 있다.

핵심은 예시 데이터가아니라 명세를 참고해 타입을 생성한다는 것이다. 명세를 참고해 타입을 생성하면 눈앞에 있는 데이터들만 고려하게 되므로 예기치 않은 곳에서 오류가 발생할 수 있다.

interface BoundingBox {  
  lat: [number, number]  
  lng: [number, number]  
}  
type GeoJSONFeature = any  
function calculateBoundingBox(f: GeoJSONFeature): BoundingBox | null {  
  let box: BoundingBox | null = null  
  
  const helper = (coords: any[]) => {  
    // ...  
  }  
  
  const { geometry } = f  
  if (geometry) {  
    helper(geometry.coordinates)  
  }  
  return box  
}

Feature 타입은 명시적으로 정의된 적이 없다.

그러나 공식 GeoJSON 명세를 사용하는 것이 더 낫다. 다행이도 DefinitelyTyped에는 이미 타입스크립트 타입 선언이 존재한다.

$npm install --save-dev @types/geojson
# @types/[email protected]

GeoJSON 선언을 넣는 순간, 타입스크립트는 오류를 발생시킨다.

// requires node modules: @types/geojson  
  
interface BoundingBox {  
  lat: [number, number]  
  lng: [number, number]  
}  
import { Feature } from 'geojson'  
  
function calculateBoundingBox(f: Feature): BoundingBox | null {  
  let box: BoundingBox | null = null  
  
  const helper = (coords: any[]) => {  
    // ...  
  }  
  
  const { geometry } = f  
  if (geometry) {  
    helper(geometry.coordinates)  
    // ~~~~~~~~~~~  
    // Property 'coordinates' does not exist on type 'Geometry'    //   Property 'coordinates' does not exist on type    //   'GeometryCollection'  }  
  
  return box  
}

API 호출에도 비슷한 고려사항들이 적용된다. API의 명세로부터 타입을 생성할 수 있다면 그렇게 하는 것이 좋다.

만약 명세 정보나 공식 스키마가 없다면 데이터로부터 타입을 생성해야 한다. 이를 위해 quicktype 같은 도구를 사용할 수 있다. 그러나 생성된 타입이 실제 데이터와 일치하지 않을 수 있다는 점을 주의해야 한다.