Item11-13.md

item11 ~ item13

아이템11 | 잉여 속성 체크의 한계 인지하기

Recognize the Limits of Excess Property Checking

• 타입이 명시된 변수에 객체 리터럴을 할당할 때 타입스크립트는 해당 타입의 속성이 있는지 ‘그 외의 속성은 없는지’ 확인

interface Room {
  numDoors: number;
  ceilingHeightFt: number;
}
const r1: Room = {
  numDoors: 1,
  ceilingHeightFt: 10,
  elephant: 'present',
// ~~~~~~~~~~~~~~~~~~ Object literal may only specify known properties,
//                    and 'elephant' does not exist in type 'Room'
};

const obj = {
  numDoors: 1,
  ceilingHeightFt: 10,
  elephant: 'present',
};
const r2: Room = obj;  // OK

• r1의 경우. Room 인터페이스에 선언되지 않은 속성이 추가되었을 때, ‘구조적 타이핑’ 관점에서 보면 오류가 발생하지 않아야 하지만 발생.
• obj 객체에서 추론된 타입은 Room 타입(의 부분 집합)을 포함하므로 Room 타입에 할당 가능하며, 타입체커도 통과
• r1 에서는 잉여 속성 체크 라는 과정이 수행
• 잉여 속성 체크는
  • 조건에 따라 동작하지 않음
  • 통상적인 할당 가능 검사와 함꼐 쓰이면 구조적 타이핑이 무엇인지 헷갈림
  • 할당 가능 검사와는 별도의 과정

interface Options {
  title: string;
  darkMode?: boolean;
}
function createWindow(options: Options) {
  if (options.darkMode) {
    // setDarkMode();
  }
  // ...
}
createWindow({
  title: 'Spider Solitaire',
  darkmode: true
// ~~~~~~~~~~~~~ Object literal may only specify known properties, but
//               'darkmode' does not exist in type 'Options'.
//               Did you mean to write 'darkMode'?
});

const o1: Options = document;  // OK
const o2: Options = new HTMLAnchorElement;  // OK

• 위 코드는 런타임 오류는 없으나 타입스크립트 오류만 발생.
• Options 타입의 경우, 어떤 객체가 title 속성(string 타입)을 가지고 있다면 - 단, darkMode 값이 없거나 boolean 타입이어야 함 - 그 객체는 모두 Options 타입 범위에 속함.
• 그래서 o1, o2 도 title 속성(string 타입)을 가지고 있어서 정상 동작.
• 잉여 속성 체크 를 이용하면, 객체 리터럴에 알 수 없는 속성을 허용하지 않음으로써 문제점을 방지
  • so, 엄격한 객체 리터럴 체크 라고 불리기도
• document, new HTMLAnchorElement 는 객체 리터럴이 아니기 때문에 잉여 속성 체크 안됨
• { title, darkmode } 객체는 잉여 속성 체크 가능

const o1: Options = { darkmode: true, title: 'Ski Free' };
                  // ~~~~~~~~ 'darkmode' does not exist in type 'Options'...

const intermediate = { darkmode: true, title: 'Ski Free' };
const o2: Options = intermediate;  // OK

const o3 = { darkmode: true, title: 'Ski Free' } as Options;  // OK

• o1 의 오른쪽은 객체 리터럴, o2 의 오른쪽은 객체 리터럴이 아님. 그래서 잉여 속성 체크가 적용되지 않음.
• 잉여 속성 체크는 타입 단언문을 사용할 때에도 적용되지 않음 - o3
  • 그래서 타입 단언문보다 선언문을 사용해야 한다!

interface Options {
  darkMode?: boolean;
  [otherOptions: string]: unknown;
}
const o: Options = { darkmode: true };  // OK

• 잉여 속성 체크를 원하지 않으면, 인덱스 시그니처를 사용해 타입스크립트가 추가적인 속성을 예상하도록 함

interface LineChartOptions {
  logscale?: boolean;
  invertedYAxis?: boolean;
  areaChart?: boolean;
}
const opts = { logScale: true };
const o: LineChartOptions = opts;
   // ~ Type '{ logScale: boolean; }' has no properties in common
   //   with type 'LineChartOptions'

• 선택적 속성만 가지는 약한(weak) 타입에도 비슷한 체크가 동작

• 구조적 관점에서 LineChartOptions 타입은 모든 객체를 포함할 수 있음

• 이런 약한 타입은 타입스크립트가 값 타입과 선언 타입에 공통된 속성이 있는지 별도로 확인

• 공통 속성 체크는 잉여 속성 체크와 비슷하게 오타를 잡는데 효과적, 구조적으로 엄격하지 않음

• 잉여 속성 체크와 다른 점은 약한 타입과 관련된 할당문마다 수행. 임시 변수를 제거해도 공통 속성 체크는 동작함

• 잉여 속성 체크는

  • 구조적 타이핑 시스템에서 허용되는 실수를 줄여줌
  • 선택적 필드를 포함하는 타입에 특히 유용
  • 적용 범위가 제한적, 오직 객체 리터럴에만 적용

아이템12 | 함수 표현식에 타입 적용하기

Apply Types to Entire Function Expressions When Possible

• js, ts 에서는 함수 문장(statement)과 함수 표현식(expression)을 다르게 인식

function rollDice1(sides: number): number { /* COMPRESS */ return 0; /* END */ }  // Statement

const rollDice2 = function(sides: number): number { /* COMPRESS */ return 0; /* END */ };  // Expression
const rollDice3 = (sides: number): number => { /* COMPRESS */ return 0; /* END */ };  // Also expression

• 타입스크립트에서는 함수 표현식을 사용하는 것이 좋다.

  → 함수의 매개변수부터 반환값까지 전체를 함수 타입으로 선언, 함수 표현식에 재사용 가능

type DiceRollFn = (sides: number) => number;
const rollDice: DiceRollFn = sides => { /* COMPRESS */ return 0; /* END */ };
// 여기에서 ts가 이미 sides의 타입을 number로 인식

• 함수 타입 선언의 장점 : 불필요한 코드의 반복 줄임

function add(a: number, b: number) { return a + b; }
function sub(a: number, b: number) { return a - b; }
function mul(a: number, b: number) { return a * b; }
function div(a: number, b: number) { return a / b; }

// 반복되는 함수 시그니처를 하나의 함수 타입으로 통합
type BinaryFn = (a: number, b: number) => number;
const add: BinaryFn = (a, b) => a + b;
const sub: BinaryFn = (a, b) => a - b;
const mul: BinaryFn = (a, b) => a * b;
const div: BinaryFn = (a, b) => a / b;

• 라이브러리는 공통 함수 시그니처를 타입으로 제공하기도

  • ex) 리액트는 MouseEvent(함수의 매개변수에 명시) 타입 대신, 함수 전체에 적용할 수 있는 MouseEventHandler 타입 제공

• 시그니처가 일치하는 다른 함수가 있을 때도 함수 표현식에 타입 적용 가능

  • 다른 함수의 시그니처를 참조하려면 typeof fn 사용

declare function fetch(
  input: RequestInfo, init?: RequestInit
): Promise<Response>;

async function checkedFetch(input: RequestInfo, init?: RequestInit) {
  const response = await fetch(input, init);
  if (!response.ok) {
    // Converted to a rejected Promise in an async function
    throw new Error('Request failed: ' + response.status);
  }
  return response;
}

// 함수의 매개변수와 리턴 타입까지 보장
const checkedFetch: typeof fetch = async (input, init) => {
  const response = await fetch(input, init);
  if (!response.ok) {
    throw new Error('Request failed: ' + response.status);
  }
  return response;
}

// 실수로 error를 return 했을 경우에도 함수 타입 선언 덕분에 오류를 감지
// 함수 표현식이 아니라 함수 문장 형태인 경우, checkedFetch 구현체에 오류가 발생하는게 아닌 이 함수를 호출한 위치에서 발생
const checkedFetch: typeof fetch = async (input, init) => {
  //  ~~~~~~~~~~~~   Type 'Promise<Response | HTTPError>'
  //                     is not assignable to type 'Promise<Response>'
  //                   Type 'Response | HTTPError' is not assignable
  //                       to type 'Response'
  const response = await fetch(input, init);
  if (!response.ok) {
    return new Error('Request failed: ' + response.status);
  }
  return response;
}

아이템13 | 타입과 인터페이스의 차이점 알기

Know the Differences Between type and interface

• 타입스크립트에서 명명된 타입(named type)을 정의하는 방법 : 대부분의 경우 둘 중 아무거나 사용해도 됨

// 타입
type TState = {
  name: string;
  capital: string;
}
// 인터페이스
interface IState {
  name: string;
  capital: string;
}

// 타입과 인터페이스 앞에 T/I 붙이지 말것

• 인터페이스 대신 클래스 사용 가능. 그러니 클래스는 값으로도 사용되는 js 런타임 개념

🐰 인터페이스, 타입의 비슷한 점 🐰

• 둘 중 어느 것으로 타입을 정의하든 상태에는 차이가 없음

  // 추가 속성을 함께 할당하면 타입, 인터페이스 선언 둘 다 동일한 오류 발생
  const wyoming: TState = {
    name: 'Wyoming',
    capital: 'Cheyenne',
    population: 500_000
  // ~~~~~~~~~~~~~~~~~~ Type ... is not assignable to type 'TState'
  //                    Object literal may only specify known properties, and
  //                    'population' does not exist in type 'TState'
  };

• 인덱스 시그니처 사용 가능

  type TDict = { [key: string]: string };
  interface IDict {
    [key: string]: string;
  }

• 함수 타입도 정의 가능

  type TFn = (x: number) => string;
  interface IFn {
    (x: number): string;
  }
  
  const toStrT: TFn = x => '' + x;  // OK
  const toStrI: IFn = x => '' + x;  // OK
  
  // 함수 타입에 추가적인 속성이 있는 경우
  type TFnWithProperties = {
    (x: number): number; // '=>' 이용해 함수를 정의할 수도 있음. 내용의 차이는 있다
    prop: string;
  }
  interface IFnWithProperties {
    (x: number): number;
    prop: string;
  }
  
  // 여기 잘 모르겠음. 함수 정의를 이렇게도 하나

  → 단순한 함수 타입은 타입 별칭(alias) 이 더 나은 선택. 추가 속성이 있는 경우 둘 다 차이 없음

• 제너릭 사용 가능

  type TPair<T> = {
    first: T;
    second: T;
  }
  interface IPair<T> {
    first: T;
    second: T;
  }

• 인터페이스 - 타입 확장 가능 타입 - 인터페이스 확장 가능

  interface IStateWithPop extends TState {
    population: number;
  }
  type TStateWithPop = IState & { population: number; };

  ❗ 인터페이스는 유니온 타입같은 복잡한 타입은 확장 불가

  ❗ 복잡한 타입을 확장하고 싶으면 타입과 & 사용

• 클래스 구현(implements)할 때 사용 가능

  class StateT implements TState {
    name: string = '';
    capital: string = '';
  }
  class StateI implements IState {
    name: string = '';
    capital: string = '';
  }

🐰 인터페이스, 타입의 다른 점 🐰

• 유니온 타입은 있지만 유니온 인터페이스는 없음

  type AorB = 'a' | 'b';

• 인터페이스는 타입을 확장할 수 있지만 유니온은 할 수 없음.

  // 유니온 타입을 확장하는게 필요할 경우. 
  // 타입을 하나의 변수명으로 매핑하여 인터페이스 정의하는 예제
  type Input = { /* ... */ };
  type Output = { /* ... */ };
  interface VariableMap {
    [name: string]: Input | Output;
  }
  
  // 유니온 타입에 name 속성을 붙인 타입을 만들수도
  type NamedVariable = (Input | Output) & { name: string };

  → 이 타입은 인터페이스로 표현 불가

  → 일반적으로 type 키워드는 interface 보다 쓰임새가 많다.

• 튜플과 배열 타입도 type 키워드 이용해 더 간결하게 표현 가능

  type Pair = [number, number];
  type StringList = string[];
  type NamedNums = [string, ...number[]];
  
  // 인터페이스로 튜플 비스므레하게 구현한 경우
  // 튜플에서 사용할 수 있는 concat 같은 메서드 사용 불가
  interface Tuple {
    0: number;
    1: number;
    length: 2;
  }
  const t: Tuple = [10, 20];  // OK

• 인터페이스는 보강(augment)이 가능

  interface IState {
    name: string;
    capital: string;
  }
  interface IState {
    population: number;
  }
  const wyoming: IState = {
    name: 'Wyoming',
    capital: 'Cheyenne',
    population: 500_000
  };  // OK

  • 이 처럼 속성을 확장하는 것 → 선언 병합(declaration merging)

  • 선언 병합은 주로 타입선언 파일에서 사용

    → 타입 선언 파일을 작성할 때는 선언 병합을 지원하기 위해 반드시 인터페이스를 사용해야하고, 표준을 따라야 함

  • 병합은 선언처럼 일반적인 코드에서도 지원

  • 타입은 기존 타입에 추가적인 보강이 없는 경우에만 사용해야함

• 결론

  • 복잡한 타입이면 타입 별칭 사용
  • 간단한 객체 타입이면
    • 일관성의 관점 : 일관되게 인터페이스를 사용하는 프로젝트에선 인터페이스, 일관되게 타입을 사용하는 경우엔 타입
    • 보강의 관점 : 향후 타입 선언에 보강의 가능성이 있다면 인터페이스 추천
  • 프로젝트 내부적으로 사용되는 타입에 선언 병합이 발생하는 것은 잘못된 설계 → 타입을 사용해야 함

Item28 ~ Item30