Tip-02. 타입 설계

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

type에 따라 layout과 paint가 정해진다고 가정해보자.
type이 fill일 때 FillLayout, FillPaint이여야 한다면 아래의 코드는 정확하지 않다.

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

아래처럼 개선하자.

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

동시에 값이 존재하거나 없는 데이터 타입은 묶어주자

interface Persion {
  name: string;
  // 두 데이터는 동시에 있거나 없다.
  placeOfBirth?: string;
  dateOfBirth?: Date;
}

아래와 같이 개선 가능하다.

interface Persion {
  name: string;
  // 두 데이터는 동시에 있거나 없다.
  birth?: {
    place: string;
    date: Date;
  };
}

// 혹은 아래와 같이 나눌 수도 있다.
interface Name {
  name: string;
}
interface PersonWithBirth extends Name {
  placeOfBirth: string;
  dateOfBirth: Date;
}

type Person = Name | PersonWithBirth;

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

function pluck(records, key) {
  returnrecords.map((r) => r[key]);
}

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

api처럼 들어오는 타입이 바뀔 수 있는 경우에는 타입을 구체적으로 선언하지 말자.
GeoPosition에 위,경도만 들어오리라는 보장이 없다. api가 개선되어 다른 데이터가 들어올 수 있으므로 number[]를 사용하는 것이 더 안전할 것이다.

type GeoPosition = [number, number];
interface Point {
  type: 'Point';
  coordinates: GeoPosition;
}