타입스크립트에서 타입을 좁히는 방법

실무에서 타입스크립트를 1년 정도 다루며 더 깊은 이해의 필요성을 느끼던 참에 '이펙티브 타입스크립트'라는 책을 읽게 됐고 실용적인 내용이 많아 정리해두려고 합니다.

타입스크립트의 유니온 연산자를 활용하면 여러 타입의 합집합을 정의할 수 있습니다. 그리고 어딘가에서 원하는 타입인지 확인하는 과정이 필요합니다. 이를 '타입 좁히기(narrowing)'라 합니다.

이 글에는 타입을 좁히는 여러 가지 방법을 정리하고 실무에서 태그된 유니온(tagged union)을 활용해 개선했던 사례를 담았습니다.

타입스크립트 컴파일러의 특징

타입스크립트의 타입은 '제거 가능(erasable)'합니다. 실제로 자바스크립트로 컴파일되는 과정에서 모든 인터페이스, 타입, 타입 구문은 그냥 제거되어 버립니다.

타입스크립트는 프로젝트에 설정된 버전의 자바스크립트로 트랜스파일¹됩니다. 변환된 결과물이 자바스크립트라는 건 우리가 작성한 타입과 관련된 구문들이 제거된다는 뜻입니다.

여기서 궁금한 점이 생깁니다. 만약 유니온으로 정의된 타입을 전달 받는 함수가 있다면 타입이 제거된 자바스크립트 런타임에서 어떻게 특정 타입인 것을 어떻게 보장할 수 있을까요? 우선 타입이 제거될 경우 어떤 문제가 생길 수 있는지 살펴보겠습니다.

타입이 정의된 코드는 문제가 되는 부분을 작성 단계에서 정확히 찾아냅니다.

interface Dog {
  run: VoidFunction;
}

interface Bird {
  fly: VoidFunction;
}

function runAway(animal: Dog | Bird) {
  animal.run();
      // ~~~ Property 'run' does not exist on type 'Bird'.
}

하지만 아래와 같은 타입스크립트 컴파일러 특성으로 인해 심각한 버그를 지닐 수 있습니다.

타입 오류가 존재하더라도 코드 생성(컴파일)은 가능합니다. 자바스크립트 타임은 런타임에 사용할 수 없습니다.

만약 tsconfig.json 파일에 noEmitError라는 옵션을 활성화하지 않으면 타입 에러와 무관하게 자바스크립트로 변환될 수 있습니다. 그 결과 런타임에서 아래와 같은 에러를 발생시킵니다.

function runAway(animal) {
  animal.run();
}

const animal = { 
  fly: () => console.log(`Let's fly!`),
};

runAway(animal)
// Uncaught TypeError: animal.run is not a function

특정 타입을 보장하려면 런타임 코드에서도 타입을 좁힐 방안이 필요합니다.

null, instanceof, typeof, 속성 체크

자바스크립트 변수의 타입과 문법을 활용해 전달된 값을 체크하는 비교적 간단한 방법입니다.

const button = document.getElementById('button'); // HTMLElement | null

// falsy 값 체크로 타입 좁히기
if (button) {
  button // HTMLElement
} else {
  button // null
}

// 인스턴스 여부 체크로 타입 좁히기
function printTime(date: number | Date) {
  if (date instanceof Date) {
    date // Date
  } else {
    date // number
  }
}

// typeof 체크로 타입 좁히기
function stringify(value: number | string) {
  if (typeof value === 'string') {
    value // string
  } else {
    value // number
  }
}

// 속성 유무 체크로 타입 좁히기
interface Dog {
  run: VoidFunction;
}

interface Bird {
  fly: VoidFunction;
}

function runAway(animal: Dog | Bird) {
  if ('run' in animal) {
    animal // Dog
  }
  
  if ('fly' in animal) {
    animal // Bird
  }
}

이 글의 초반부에서 나왔던 유니온 타입을 좁히는 문제는 속성 체크로 쉽게 해결이 가능해 보입니다. 하지만 실무에서 이 방식을 적용하기 어려운 사례가 있었습니다.

리모트에서 제공되는 여러 유형의 데이터가 거의 유사한 UI로 제공되는 케이스인데요, 예를 들어보면 아래와 같습니다.

type ArticleA = {
  field1: string;
  field2: string;
  author: string;
};

type ArticleB = {
  field2: string;
  field3: string;
  author: string;
};

type ArticleC = {
  field3: string;
  field4: string;
  author: string;
};

React로 구현한다고 가정했을 때 코드 중복을 줄이기 위해 컴포넌트를 재사용할 가능성이 높습니다.

type Props = {
  content: ArticleA | ArticleB | ArticleC;
};

const Article: FC<Props> = ({ content }) => {
  return (
    <article>
      <p>{content.author}</p>
    </article>
  );
};

이 시점부터 고민이 됩니다. 공통된 필드인 author는 별다른 조건 없이 바로 사용할 수 있습니다. (유니온 연산의 특성은 이전 글에서 설명된 바 있습니다)

하지만 field1부터 field4는 공통된 필드가 아니기 때문에 타입 좁히기가 필요합니다. 앞서 나온 방법 중 속성 체크가 가장 먼저 떠오릅니다.

type Props = {
  content: ArticleA | ArticleB | ArticleC;
};

const Article: FC<Props> = ({ content }) => {
  if ('field1' in content) {
    content // ArticleA
  }

  if ('field2' in content) {
    content // ArticleA | ArticleB
  }

  return (...);
};

ArticleA에만 존재하는 field1은 쉽게 타입 좁혀집니다. 반면 두 인터페이스에 존재하는 field2는 좁힐 방안이 마땅치 않습니다. 그리고 리모트 데이터 특성상 필드의 변동 가능성도 배제할 수 없습니다.

이러한 상황에서 적용할 수 있는 방법은 명시적 태그를 붙이는 것입니다.

태그된 유니온 (tagged union)

태그된 유니온 또는 구별된 유니온(discriminated union)이라 불리는 이 방법은 타입을 식별하기 위해 명시적 '태그'를 붙이는 것입니다. 앞서 나왔던 각 타입을 식별할 수 있는 필드를 추가합니다.

type ArticleA = {
  kind: 'a';
  field1: string;
  field2: string;
  author: string;
};

type ArticleB = {
  kind: 'b';
  field2: string;
  field3: string;
  author: string;
};

type ArticleC = {
  kind: 'c';
  field3: string;
  field4: string;
  author: string;
};

이제 kind 필드를 활용하면 각 타입의 필드 변화에 영향을 받지 않고 구분할 수 있습니다.

type Props = {
  content: ArticleA | ArticleB | ArticleC;
};

const Article: FC<Props> = ({ content }) => {
  if (content.kind === 'a') {
    content // ArticleA
  }

  if (content.kind === 'b') {
    content // ArticleB
  }

  return (...);
};

어떻게 보면 단순해 보이지만 자바스크립트 런타임에도 타입을 보장할 수 있는 유용한 방법입니다.

사용자 정의 타입 가드 (user-defined type guard)

때로는 타입스크립트 컴파일러보다 코드 작성자가 타입을 더 정확히 알고 있는 경우가 있습니다. DOM과 관련된 처리가 대표적인 예시입니다.

타입스크립트에서는 추상화된 수준에 따라 DOM 계층의 타입들이 구분됩니다. 아래 표는 계층 구조의 예시입니다.

서브타입 관계가 다양하기 때문에 DOM 관련 코드를 작성할 때는 타입을 구체화하기 위한 단언문을 사용하거나 아래와 같은 사용자 정의 타입 가드를 활용할 수 있습니다.

function isInputElement(el: HTMLElement): el is HTMLInputElement {
  return 'value' in el;
}

function getElementContent(el: HTMLElement) {
  if (isInputElement(el)) {
    el // HTMLInputElement
  } else {
    el // HTMLElement
  }
}

마무리

분기문 외에도 여러 종류의 제어 흐름을 살펴보며 타입스크립트가 타입을 좁히는 과정을 이해해야 합니다.

타입이 좁혀지는 과정을 확인할 때 간단한 코드는 TypeScript Playground 사이트를 활용하면 유용합니다. 그리고 VSCode와 같이 타입스크립트 지원이 잘되는 IDE에서는 커서만 올려도 타입 정보가 나오고, 타입 정의를 쉽게 추적할 수 있습니다. 이러한 도구를 활용해 코드를 작성하고 로직을 쌓아가는 과정에서 중간중간 타입이 어떻게 추론되고 있는지 수시로 확인해야 나중에 타입 디버깅을 위한 비용을 줄일 수 있을 것입니다.
그리고 상황에 따라 런타입 분기 문법과 태그된 유니온, 사용자 정의 타입 가드 등의 기법을 잘 활용해야겠습니다.