📄 Item11 ~ 15

Item11. 잉여 속성 체크의 한계 인지하기

• 다음 두 예제의 차이를 알아보자.

// example 1

interface Room {
  numDoors: number;
  ceilingHeightFt: number;
}

const r: Room = {
  numDoors: 1,
  ceilingHeightFt: 10,
  elephant: 'present',
}

// example 2

interface Room {
  numDoors: number;
  ceilingHeightFt: number;
}

const obj = {
  numDoors: 1,
  ceilingHeightFt: 10,
  elephant: 'present',
}

const r: Room = obj;

• example 1에서 r은 타입 체커가 해당되는 속성이 없기 때문에 에러를 발생한다.
• example 2에서 obj 타입은 { numDoors: number; ceilingHeightFt: number; elephant: string }으로 추론되어 obj 타입은 Room 타입의 부분 집합을 포함하므로, Room에 할당 가능하며 타입 체커도 통과한다.
• 첫 번째 예시의 경우, 구조적 타입 시스템에서 발생할 수 있는 중요한 오류 중 하나인 '잉여 속성 체크' 과정이 수행되어서 오류를 발생했다.
• 잉여 속성 체크가 할당 가능검사와는 별도의 과정이라는 것을 알아야 타입스크립트 타입 시스템에 대한 개념을 정확히 잡을 수 있다.

interface Options {
  title: string;
  darkMode?: boolean;
}

function createWindow(options: Options) {
  if (options.darkMode) {
    setDarkMode();
  }
}

createWindow({
  title: 'Spider Solitaire',
  darkmode: true,
})

• 위 코드를 실행하면 런타임에 어떤 종류의 오류도 발생하지 않는다.
  • 그러나 타입스크립트가 "객체 리터럴은 알려진 속성만 지정할 수 있지만 'Options' 형식에 'darkmode'이(가) 없습니다. 'darkMode'을(를) 쓰려고 했습니까?"와 같은 오류 메시지처럼 의도한 대로 동작하지 않을 수 있다.
• Options 타입은 범위가 매우 넓어 순수한 구조적 타입 체커는 이러한 종류의 오류를 찾아내지 못한다.

// 둘다 string 타입인 title 속성을 가지고 있어서 할당문은 정상(두 가지 모두 객체 리터럴이 아니므로 잉여 속성 체크가 되지 않음)

const o1: Options = document; // 정상
const o2: Options = new HTMLAnchorElement; // 정상

• 잉여 속성 체크를 이용하면 기본적으로 타입 시스템의 구조적 본질을 해치지 않으면서도 객체 리터럴에 알 수 없는 속성을 허용하지 않음으로써 오류를 막을 수 있다.

// 아래 구문은 객체 리터럴이므로 잉여 속성 체크가 된다.

const o3: Options = { darkmode: true, title: 'Ski Free' }; // ~~~ 'Options' 형식에 'darkmode'이(가) 없습니다.

// 타입 단언문을 사용하게 되면 잉여 속성 체크가 적용되지 않으므로 가급적이면 선언문을 이용해야 한다.

const o4 = { darkmode: true, title: 'Ski Free' } as Options; // 정상

• 만약 잉여 속성 체크를 원치 않는다면, 인덱스 시그니처를 사용해서 타입스크립트가 추가적인 속성을 예상하도록 할 수 있다.

interface Options {
  [otherOptions: string]: unknown;
  darkMode?: boolean;
}

const o5: Options = { darkmode: true }; // 정상

Item12. 함수 표현식에 타입 적용하기

---

➕ 함수 문장과 함수 표현식

• 표현식(expressions)
  • 값 하나로 귀결되는 자바스크립트 코드 조각
  • 자바스크립트 코드 중 값이 들어가는 곳이면 어디에나 넣을 수 있다.
• 문장(statements)
  • 자바스크립트에서 문장은 값이 들어와야 할 곳에 들어갈 수 없다.
  • 이 들은 함수의 인자로도, 대입연산의 값으로도, 연산자의 피연산자로도 사용될 수 없다.

function rollDice1(sides) { ... } // 함수 문장
const rollDice2 = function(sides) { ... } // 함수 표현식
const rollDice3 = (sides) => { ... } // 함수 표현식

• 함수 문장과 함수 표현식의 차이
  • '함수 문장'으로 정의된 함수는 해당 함수를 호출하는 코드가 함수를 정의하는 문장보다 앞에 있건 뒤에 있건 유효봄위(함수 유효범위)만 같으면 문제 없다.
  • 하지만 '함수 표현식'으로 정의된 함수는 함수를 정의하는 문장보다 뒤에 있어야만 한다.

foo(); // 정상 동작

function foo() {
  alert('call foo');
}


bar(); // 비정상 동작

const bar = function() {
  alert('call bar');
}

📖 Reference

• https://velog.io/@fromzoo/%ED%91%9C%ED%98%84%EC%8B%9DExpression%EA%B3%BC-%EB%AC%B8%EC%9E%A5Statement

• https://dimdim.tistory.com/entry/%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8-%ED%95%A8%EC%88%98%EB%AC%B8%EC%9E%A5-%EA%B3%BC-%ED%95%A8%EC%88%98%ED%91%9C%ED%98%84%EC%8B%9D%EC%9D%98-%EC%B0%A8%EC%9D%B4

---

• 타입스크립트에서는 함수 표현식을 사용하는 것이 좋다.
  • 함수의 매개변수부터 반환값까지 전체를 함수 타입으로 선언하여 함수 표현식에 재사용할 수 있다는 장점이 있기 때문이다.
  • 그리고 불필요한 코드의 반복을 줄일 수도 있다.
• 라이브러리는 공통 함수 시그니처를 타입으로 제공하기도 한다.
  • 직접 라이브러리를 만든다면, 공통 콜백 함수를 위한 타입 선언을 제공하는 것이 좋다.
• 예시) 웹 브라우저에서 fetch 함수

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) {
    // 비동기 함수 내에서 거절된 프로미스로 변환
    throw new Error(`Request failed: ${response.status}`);
  }
    
  return response;
}

// 위 코드에서 더 간결해진 버전
// 1. 함수 문자을 함수 표현식으로 교체
// 2. 함수 전체에 타입(typeof fetch)을 적용 => 타입스크립트가 input과 init의 타입을 추론할 수 있게 해 줌

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;
}

• 함수의 매개변수에 타입 선언을 하는 것보다 함수 표현식 전체 타입을 정의하는 것이 코드도 간결하고 안전하다.
  • 다른 함수의 시그니처와 동일한 타입을 가지는 새 함수를 작성하거나, 동일한 타입 시그니처를 가지는 여러 개의 함수를 작성할 때는 매개변수의 타입과 변환 타입을 반복해서 작성하지 말고 함수 전체의 타입 선언을 적용해야 한다.

Item13. 타입과 인터페이스의 차이점 알기

(1) 공통점

• 명명된 타입일 때는 타입, 인터페이스 모두 추가 속성과 함께 할당하면 아래 코드와 같이 동일한 오류가 발생한다.

type TUser = {
  name: string;
  age: number;
}

interface IUser {
  name: string;
  age: number;
}

const wally: TUser = {
  name: 'wally',
  age: 28,
  zipCode: 12345, // 형식 'TUser' 형식에 할당할 수 없다. 객체 리터럴은 알려진 속성만 지정할 수 있으며 'TUser' 형식에 'zipCode'이(가) 없다.
}

• 인덱스 시그니처는 인터페이스, 타입 모두 사용할 수 있다.

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; // 정상
const toStrI: IFn = x => '' + x; // 정상

• 타입 별칭과 인터페이스 모두 제네릭이 가능하다.

• 인터페이스는 타입을, 타입은 인터페이스를 확장할 수 있다.

  • 단, 주의할 점은 인터페이스는 유니온 타입 같은 복잡한 타입을 확장하지는 못한다.
  • 복잡한 타입을 확장하고 싶다면 타입과 &를 사용해야 한다.

interface IStateWithPop extends TState {
  population: number;
}

type TStateWithPop = IState & { population: number };

• 클래스를 구현(implements)할 때는 타입과 인터페이스 둘 다 사용할 수 있다.

(2) 차이점

• 유니온 타입은 있지만 유니온 인터페이스라는 개념은 없다.
• 인터페이스는 타입을 확장할 수 있지만, 유니온은 할 수 없다.
  • 그런데 유니온 타입을 확장하는 게 필요할 때가 있다.

type Input = { ... };
type Output = { ... };

interface VariableMap {
  [name: string]: Input | Output;
}

• 또는 유니온 타입에 name 속성을 붙인 타입을 만들 수도 있다.

// 이 타입은 인터페이스로 표현할 수 없다.
// type 키워드는 유니온이 될 수 있고, 매핑된 타입 또는 조건부 타입 같은 고급 기능에 활용되기도 한다.

type NamedVariable = (Input | Output) & { name: string };

• 튜플과 배열 타입도 type 키워드를 이용해 더 간결하게 표현할 수 있다.
  • 인터페이스로도 튜플과 비슷하게 구현할 수 있으나 튜플에서 사용할 수 있는 concat 같은 메소드들을 사용할 수 없다.

type Pair = [number, number];
type StringList = string[];
type NamedNums = [string, ...number[]];

• 인터페이스는 타입에 없는 '보강(augment)' 이 가능하다.
  • 아래 코드와 같이 '선언 병합(declaration merging)'을 이용해서 인터페이스를 보강할 수 있다.
  • 타입 선언 파일을 작성할 대는 선언 병합을 지원하기 위해 반드시 인터페이스를 사용해야 하며 표준을 따라야 한다.
  • 타입 선언에는 사용자가 채워야 하는 빈틈이 있을 수 있는데, 바로 이 선언 병합이 그렇다.

interface IState {
  name: string;
  captial: string;
}

interface IState {
  population: number;
}

const wyoming: IState {
  name: 'Wyoming',
  captial: 'Cheyenne',
  population: 500000,
}; // 정상

• 병합은 선언과 마찬가지로 일반적인 코드에서도 지원되므로 언제 병합이 가능한지 알고 있어야 한다.
  • 타입은 기존 타입에 추가적인 보강이 없는 경우에만 사용해야 한다.

(3) 타입과 인터페이스 중 어떤 것을 써야할까

• 복잡한 타입이라면 고민할 것도 없이 타입 별칭을 사용하면 된다.
• 타입과 인터페이스, 두 가지 방법으로 모두 표현할 수 있는 간단한 객체 타입이라면 일관성과 보강의 관점에서 고려해 봐야 한다.
  • 일관되게 인터페이스를 사용하는 코드베이스에서 작업하고 있다면 인터페이스를 사용하고, 일관되게 타입을 사용 중이라면 타입을 사용하면 된다.
• 어떤 API에 대한 타입 선언을 작성해야 한다면 인터페이스를 사용하는 게 좋다.
  • API가 변경될 때 사용자가 인터페이스를 통해 새로운 필드를 병합할 수 있어 유용하기 때문이다.

Item14. 타입 연산과 제네릭 사용으로 반복 줄이기

• DRY(Don't Repeat Yourself) 원칙을 타입에도 최대한 적용해야 한다.
• 타입에 이름을 붙여서 반복을 피해야 한다.
  • extends를 사용해서 인터페이스 필드의 반복을 피해야 한다.

---

⭐️ 예시1 - mapped type

// before

interface State { 
  userId: string;
  pageTitle: string;
  recentFiles: string[];
  pageContents: string;
}

interface TopNavState {
  userId: string;
  pageTitle: string;
  recentFiles: string[];
}

// 1) State 인덱싱

type TopNavState = {
  userId: State['userId'];
  pageTitle: State['pageTitle'];
  recentFiles: State['recentFiles'];
}

// 2) mapped type 적용

type TopNavState = {
  [k in 'userId' | 'pageTitle' | 'recentFiles']: State[k]
}

// 3) 유틸리티 타입인 Pick 적용

type TopNavState = Pick<State, 'userId' | 'pageTitle' | 'recentFiles'>;

---

⭐️ 예시2 - 태그된 유니온

interface SaveAction {
  type: 'save';
}

interface LoadAction {
  type: 'load';
}

type Action = SaveAction | LoadAction;
type ActionType = 'save' | 'load'; // 타입의 반복!

// Action 유니온 타입을 인덱싱
type ActionType = Action['type']; // 타입은 "save" | "load"

---

⭐️ 예시3 - keyof 연산자 사용

interface Options {
  width: number;
  height: number;
  color: string;
  label: string;
}

interface OptionsUpdate {
  width?: number;
  height?: number;
  color?: string;
  label?: string;
}

class UIWidget {
  constructor(init: Options) { ... }
  update(options: OptionsUpdate) { ... }
}

// 매핑된 타입과 keyof를 사용

type OptionsKeys = keyof Options; // "width" | "height" | "color" | "label"
type OptionsUpdate = { [k in keyof Options]?: Options[k] };

// 유틸리티 타입인 Partial 적용
type OptionsUpdate = Partial<Options>;

---

⭐️ 예시4 - 값의 형태에 해당하는 타입 정의

• 값으로부터 타입을 만들어 낼 때는 선언의 순서에 주의해야 한다.
  • 타입 정의를 먼저하고 값이 그 타입에 할당 가능하다고 선언하는 것이 좋다.
  • 그렇게 해야 타입이 더 명확해지고, 예상하기 어려운 타입 변동을 방지할 수 있다.

const INIT_OPTIONS = {
  width: 640,
  height: 480,
  color: '#00FF00',
  label: 'VGA',
};

type Options = typeof INIT_OPTIONS;

• 함수나 메서드의 반환 값에 명명된 타입 만드는 경우
  • 이때는 조건부 타입이 필요하나 표준 라이브러리에는 일반적 패턴의 제네릭 타입이 정의되어 있다.
  • 이런 경우 유틸리티 타입인 ReturnType을 사용하면 된다.

function getUserInfo(userId: string) {
  // 생략
  return {
    userId,
    name,
    age,
    zipCode,
  };
}

type UserInfo = ReturnType<typeof getUserInfo>;

• typeof를 적용할 때는 적용 대상이 값인지 타입인지 정확히 알고, 구분해서 처리해야 한다.

---

⭐️ 예시5 - 제네릭 타입 제한

• 제네릭 타입은 타입을 위한 함수와 같다.
  • 타입을 반복하는 대신 제네릭 타입을 사용하여 타입들 간에 매핑을 하는 것이 좋다.
  • 제네릭 타입을 제한하려면 extends 키워드를 사용하면 된다.

interface Name {
  first: string;
  last: string;
}

type DancingDuo<T extends Name> = [T, T];

const couple1: DancingDuo<Name> = [
  { name: 'Fred', last: 'Astaire' },
  { name: 'Ginger', last: 'Rogers' },
]; // 정상

// '{ first: string; }'은 Name을 확장하지 않기 때문에 오류가 발생한다.
const couple2: DancingDuo<{first: string}> = [
  { first: 'Sonny' },
  { first: 'Cher' },
]; // 'Name' 타입에 필요한 'last' 속성이 '{ first: string; }' 타입에 없다.

• Pick을 이용해서도 동일한 모습을 볼 수 있다.

// Pick 구현 모습

// K는 실제로 T의 키의 부분 집합, 즉 keyof T가 되어야 한다.
// 또한 타입이 값의 집합이라는 관점에서 생각하면 extends를 '확장'이 아니라 '부분 집합'이라는 것으로 이해해야 한다.
type Pick<T, K extends keyof T> = {
  [k in K]: T[k]
};

type FirstLast = Pick<Name, 'first' | 'last'>; // 정상
type FirstMiddle = Pick<Name, 'first' | 'middle'>; // '"middle"' 형식은 '"first" | "last"' 형식에 할당할 수 없다.

---

Item15. 동적 데이터에 인덱스 시그니처 사용하기

// 타입스크립트에서 인덱스 시그니처 사용한 예시
type Rocket = { [property: string]: string };

const rocket: Rocket = {
  name: 'Falcon 9',
  variant: 'v1.0',
  thrust: '4,940 kN',
}; // 정상

• 인덱스 시그니처의 각 의미

분류	설명
키의 이름	키의 위치만 표시하는 용도로 타입 체커에서는 사용 안 함
키의 타입	string 이나 number 또는 symbol의 조합이어야 하지만, 보통은 string을 사용함
값의 타입	어떤 것이든 될 수 있음

• 동적 데이터에 인덱스 시그니처 사용하는 정확한 방법

interface Rocket {
  name: string;
  variant: string;
  thrust_kN: number;
}

const falconHeavy: Rocket = {
  name: 'Falcon Heavy',
  variant: 'v1',
  thrust_kN: 15200
};

• 인덱스 시그니처는 동적 데이터를 표현할 때 사용한다.
  • 예를 들어 CSV 파일처럼 헤더 행에 열 이름이 있고, 데이터 행을 열 이름과 값으로 매핑하는 객체로 나타내고 싶은 경우다.
  • 일반적인 상황에서 열 이름이 무엇인지 알기 어려울 때 아래와 같이 인덱스 시그니처를 사용하면 된다.

function parseCSV(input: string): { [columnName: string]: string }[] {
  const lines = input.split('\n');
  const [ header, ...rows ] = lines;
  const headerColumns = header.split(',');
    
  return rows.map(rowStr => {
    const row: { [columnName: string ]: string } = {};
    
    rowStr.split(',').forEach((cell, i) => {
      row[headerColumns[i]] = cell;
    });
      
    return rows;
  });
}

• 반면 열 이름을 알고 있는 특정한 상황이라면 미리 선언해 둔 타입으로 단언문을 사용한다.

interface ProductRow {
  productId: string;
  name: string;
  price: string;
}

declare let csvData: string;

const products = parseCSV(csvData) as unknown as ProductRow[];

// 선언해 둔 열들이 런타임에 실제로 일치한다는 보장이 없기 때문에 이 부분이 걱정된다면 값 타입에 undefined를 추가할 수 있다.
function safeParseCSV(input: string): { [columnName: string]: string | undefined }[] {
  return parseCSV(input);
}

// 모든 열의 undefined 여부를 체크해야 한다.
const rows = parseCSV(csvData);

const prices: { [product: string]: number } = {};

for (const row of rows) {
  prices[row.productId] = Number(row.price);
}

const saveRows = safeParseCSV(csvData);

for (const row of safeRows) {
  prices[row.productId] = Number(row.price); // 'undefined' 형식을 인덱스 형식으로 사용할 수 없다.
}

• 어떤 타입에 가능한 필드가 제한되어 있는 경우라면 인덱스 시그니처로 모델링하지 말아야 한다.

interface Row1 {
  [column: string]: number
} // 너무 광범위

interface Row2 {
  a?: number;
  b?: number;
  c?: number;
  d?: number;
} // 최선

// 1) Record를 사용하여 키 타입에 유연성 제공

type Vec3D = Record<'x' | 'y' | 'z', number>;

// 2) mapped type

type Vec3D = { [k in 'x' | 'y' | 'z']: number };

// 응용) 조건부 타입과 연결

type ABC = { [k in 'a' | 'b' | 'c']: k extends 'b' ? string : number };
// Type ABC = {
//   a: number;
//   b: string;
//   c: number;
// }