DIL: 이펙티브 타입스크립트

스터디: 월간 CS, https://github.com/monthly-cs/2024-05-effective-typescript
작성일: 2024-05-18
작성자: dusunax

---

아이템 10: 객체 래퍼 타입 피하기 Avoid Object Wrapper Types (String, Number, Boolean, Symbol, BigInt)

• 기본형 값의 7타입: string, number, boolean, null, undefined, symbol(ES2015), bigint(최종 확정 단계)
  • immutable이며 메서드를 가지지 않는다.
• 래퍼 객체: String, Number, Boolean, Symbol, BigInt

"primitive".charAt(3); // 'm'

• JavaScript promptly coerces between primitives and objects.

string의 property에 접근하려 할 때

The Wrapper Object: https://javascriptrefined.io/the-wrapper-object-400311b29151

• stirng을 String 객체로 wrapping하고 (coerce)
• 래퍼 객체에서 메서드를 호출하고 (new String(string), String의 메서드를 상속하고, 속성 참조)
• 래핑한 객체를 버린다. (property가 resolved되었을 때)

특징

// 몽키패치? 런타임에 프로그램의 어떤 기능을 수정해서 사용하는 것. js에서는 주로 프로토타입
// Don't do this!
const originalCharAt = String.prototype.charAt;
String.prototype.charAt = function (pos) {
  console.log(this, typeof this, pos); // "primitive",  "string",  3
  return originalCharAt.call(this, pos);
};
console.log("primitive".charAt(3));

• 기본형에 속성을 추가한다면? 래퍼 객체와 함께 버려짐
• 타입스크립트가 제공하는 타입 선언은 기본형 타입이다.
• string은 String에 할당할 수 있다 (String은 string에 할당할 수 없다)

const s: String = "primitive"; // 할당 가능하지만, 기본형 타입을 사용하자
const n: Number = 12;
const b: Boolean = true;

// new 키워드 없이 BigInt와 Symbol을 호출하면 기본형을 생성하기 때문에 사용해도 됨
typeof BigInt(1234); // "bigint"
typeof Symbol("sym"); // "symbol"

Things to Remember

• Avoid TypeScript object wrapper types. Use the primitive types instead: string instead of String, number instead of Number, boolean instead of Boolean, symbol instead of Symbol, and bigint instead of BigInt.
  • 래퍼 타입이 아닌 기본형(원시형) 타입 사용하기
• Understand how object wrapper types are used to provide methods on primitive values. Avoid instantiating them or using them directly, with the exception of Symbol and BigInt.
  • 래퍼 객체 타입은 원시형에 대한 메서드를 사용하기 위해 사용됨. Symbol이나 BigInt가 아니라면 직접 사용하지 않기

---

아이템 11: 잉여 속성 체크 excess property checking의 한계 인지하기 Distinguish Excess Property Checking from Type Checking

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

// A. 잉여 속성 체크
const rA: Room = {
  numDoors: 1,
  ceilingHeightFt: 10,
  elephant: "present",
  // ~~~~~~~ Object literal may only specify known properties,
  //         and 'elephant' does not exist in type 'Room'
};

// B. 구조적 타이핑
// obj는 Room 타입의 부분집합을 포함하므로 Room에 할당 가능하며 타입 체커도 통과
const obj = {
  numDoors: 1,
  ceilingHeightFt: 10,
  elephant: "present",
};
const rB: Room = obj; // 통과됨
// 잉여 속성 체크는 할당 가능 검사 structural assignability check 와는 별도의 과정

넓은 범위의 타입, excess property check

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; // document는 객체 리터럴이 아니므로 - 체크 X
const o2: Options = new HTMLAnchorElement(); // 객체 리터럴이 아니므로 - 잉여속성 체크 X
const o3: Options = { darkmode: true, title: "Ski Free" }; // 객체 리터럴이므로 - 체크 O
// ~~~~~~~~ 'darkmode' does not exist in type 'Options'...

const intermediate = { darkmode: true, title: "Ski Free" }; // right hand는 객체 리터럴이다
const o3: Options = intermediate; // right hand는 객체 리터럴이 아니다. - 체크 X

const o = { darkmode: true, title: "MS Hearts" } as Options; // 타입 단언이므로 체크 X

• 인덱스 시그니처를 사용해 추가적인 속성 예상

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

• weak type: 선택적인 속성만 가짐
  • 타입스크립트는 값 타입과 선언 타입의 공통된 속성이 있는지 확인하는 체크 수행
    • 오타 잡기, 구조적으로 엄격하지 않음
    • 선택적 필드를 포함하는 option 같은 타입에 유용

interface LineChartOptions {
  logscale?: boolean;
  invertedYAxis?: boolean;
  areaChart?: boolean;
}
function setOptions(options: LineChartOptions) {
  /* ... */
}

const opts = { logScale: true };
setOptions(opts);
//         ~~~~ Type '{ logScale: boolean; }' has no properties in common
//              with type 'LineChartOptions'

Things to Remember

• When you assign an object literal to a variable with a known type or pass it as an argument to a function, it undergoes excess property checking.

  • "객체 리터럴"을 변수에 할당하거나 함수에 매개변수로 전달할 때, 잉여 속성 체크 excess property check가 수행된다

• Excess property checking is an effective way to find errors, but it is distinct from the usual structural assignability checks done by the TypeScript type checker. Conflating these processes will make it harder for you to build a mental model of assignability. TypeScript types are not "closed" (pass:[Item 4]).

  • 잉여 속성 체크는 오류를 찾는 효과적인 방법(객체 리터럴, 타입 에러)이지만, 구조적 할당 가능성 체크와는 역할이 다르다(구조적 )

    | 검사 | 영어 | 키워드 | 설명 | | ----------------------- | ------------------------ | ------------------------------ | ------------------------------------------------------------------------------------------- | | 초과 속성 검사 | Excess Property Checking | 오타나 의도치 않은 속성을 감지 | 객체 리터럴을 다른 타입에 할당할 때 예상치 못한 속성이 있는지 확인하여 오류를 찾아내는 기능 | | 구조적 할당 가능성 검사 | Structural Assignability | 구조적 타이핑 | 타입 간의 호환성을 결정할 때 사용하는 일반적인 검사 |

  • Excess Property Checking Example:

    interface Person {
      name: string;
      age: number;
    }
    
    const person: Person = {
      name: "Alice",
      age: 25,
      extraProp: "unexpected", // Error: Object literal may only specify known properties, and 'extraProp' does not exist in type 'Person'.
    };
    

  • Structural Assignability Example:

    interface Point {
      x: number;
      y: number;
    }
    
    const point = { x: 10, y: 20, z: 30 };
    
    const assignablePoint: Point = point;
    // 오류 없음! 'point' 객체에는 'Point' 인터페이스에서 요구하는 속성이 모두 포함되어 있음.
    

• Be aware of the limits of excess property checking: introducing an intermediate variable will remove these checks.

  • 추가 속성 체크의 한계 (중간 단계의 임시 변수)

• A "weak type" is an object type with only optional properties. For these types, assignability checks require at least one matching property.

  • weak type은 옵셔널 속성으로만 이루어진 타입
  • 적어도 하나의 속성이 맞아야 할당

---

아이템 12: 함수 표현식에 타입 적용하기 Apply Types to Entire Function Expressions When Possible

statement vs expression

function rollDice1(sides: number): number {} // 문장 Statement
const rollDice2 = function (sides: number): number {}; // 표현식 Expression
const rollDice3 = (sides: number): number => {}; // 표현식 expression

함수 전체의 타입을 정의하기

type DiceRollFn = (sides: number) => number;
// 함수 타입의 선언의 목적: 불필요한 코드의 반복을 줄인다 (반복되는 함수 시그니처를 통합)
// 함수 구현부가 분리되어 로직이 분명해진다.
const rollDice: DiceRollFn = (sides) => {};

• 라이브러리의 공통 함수 시그니처: 공통 콜백함수를 위한 타입 선언

  • JS의 MouseEvent, React의 MouseEventHandler

  • MouseEventHandler는 함수 전체에 적용할 수 있는 타입이다.

    // @types/react/index.d.ts
    // MouseEventHandler
    // Element T를 제네릭으로 받아서 MouseEvent<T>로 EventHandler 타입에 넘김
    type MouseEventHandler<T = Element> = EventHandler<MouseEvent<T>>;
    
    // (참고용)EventHandler
    type EventHandler<E extends SyntheticEvent<any>> = {
      bivarianceHack(event: E): void;
    }["bivarianceHack"];
    

• 시그니처가 일치하는 다른 함수

  • 예시: fetch 타입 활용하기

// typescript/lib/lib.dom.d.ts에 있는 fetch 타입
declare function fetch(
  input: RequestInfo,
  init?: RequestInit
): Promise<Response>;

// 다른 파일에서 활용
// 함수 전체에 타입(typeof fetch)를 적용해, 매개변수의 타입을 추론할 수 있게 한다
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;
};

Things to Remember

• Consider applying type annotations to entire function expressions, rather than to their parameters and return type.
  • 파라미터와 리턴 타입을 개별로 선언하지 않고, 전체 함수 표현식의 타입을 선언하도록 한다
• If you're writing the same type signature repeatedly, factor out a function type or look for an existing one.
  • 반복적인 함수 시그니처를 작성하지 말고, 함수 타입을 분리해내거나 & 이미 존재하는 타입을 찾도록 한다
• If you're a library author, provide types for common callbacks.
  • 라이브러리를 만들 때, 공통 콜백 타입을 제공하자
• Use typeof fn to match the signature of another function, or Parameters and a rest parameter if you need to change the return type.
  • 다른 함수의 시그니처를 사용하려면 typeof fn을 사용한다

---

아이템 13 타입과 인터페이스의 차이점 알기 Know the Differences Between type and interface

• named type을 정의하는 방법
  • type과 interface로 정의
  • class는 값+타입

접두사 I, T를 사용하지 않을 이유

• (권장사항) 접두사로 I, T를 붙이는 것은 C# 관례인데, 타입스크립트 초기에 사용했었지만 지금은 커뮤니티에서 권장하지 않는 스타일이다.
• (타입스크립트 컴파일러) 타입이나 인터페이스 이름에 굳이 I나 T를 붙이지 않아도 타입스크립트 컴파일러가 이를 명확히 구분할 수 있다.
• (가독성) IUser보다 User가 더 직관적이며, TProduct보다 Product가 더 명확

type과 interface

• 공통: 추가 속성 검사, 인덱스 시그니처, 함수 타입 정의, 제네릭, 클래스 implements
• 확장
  • interface: 타입을 확장
    • 유니온 타입과 같은 복잡한 타입 확장 x (유니온 인터페이스는 없다)
  • type: 인터페이스를 확장

// 확장 extends
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 활용

• 타입 union

  type AorB = "a" | "b";
  

• 별도의 타입을 하나의 변수명으로 매핑할 때

  type Input = {
    /* ... */
  };
  type Output = {
    /* ... */
  };
  interface VariableMap {
    [name: string]: Input | Output; // union
  }
  

• union 타입에 속성을 추가한 타입

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

• 튜플, 배열

  • interface로 구현하게 되면, concat과 같은 메서드를 사용할 수 없음
  • 직관적이지 않음
  • 숫자 인덱스 문제 (아이템 16)

  type Pair = [a: number, b: number];
  type StringList = string[];
  type NamedNums = [string, ...number[]];
  
  const 페어: Pair = [0, 1];
  const 네임드넘즈: NamedNums = ["🐝", 0, 1];
  
  // Interface로 구현하는 경우
  // 타입의 형태와, 타입 에러의 메시지(하단)가 직관적이지 않음
  interface Tuples {
    0: number;
    1: number;
    length: 2;
  }
  

  • type 튜플

    • length가 1

      Type '[number]' is not assignable to type 'Pair'.
        Source has 1 element(s) but target requires 2
      

    • length가 3

      Type '[number, number, number]' is not assignable to type 'Pair'.
      Source has 3 element(s) but target allows only 2.(2322)
      

  • interface로 구현하는 경우

    • length가 1

      Property '1' is missing in type '[number]' but required in type 'Tuples'.
      

      
    • length가 3

      Type '[number, number, number]' is not assignable to type 'Tuples'.
        Types of property 'length' are incompatible.
          Type '3' is not assignable to type '2'.(2322)
      

      

보강 augment

• interface만 가능

interface IState {
  name: string;
  capital: string;
}
interface IState {
  // 보강됨!
  population: number;
}
const wyoming: IState = {
  name: "Wyoming",
  capital: "Cheyenne",
  population: 578_000,
}; // OK

• 보강을 변수 선언&할당의 하단에서 진행하는 경우에도 타입 에러 없음 (전역 범위)
• 충돌 없음: 각 보강은 이전 선언과 충돌해서는 안 됩니다(예: 동일한 이름의 속성이 다른 타입을 가지면 안 됨)
• 예제의 설명처럼 타입선언 파일(d.ts) 등에서 사용자가 채우는 경우에만 사용하는 것이 적합할 것이라 생각

선언 병합 declaration merging,

• TS는 여러 버전의 JS 표준 라이브러리에서 여러 타입을 모아 병합한다
• 예시
  • lib.es5.d.ts의 interface Array<T>
  • tsconfig.json lib에 ES2015를 추가하면? 타입스크립트는 lib.es2015.d.ts의 interface Array<T>를 병합한다 (find와 같은 메서드를 포함)

Type or Interface?

• 복잡한 타입: 타입 별칭
• 간단한 타입: 일관성과 보강의 관점에서 고려하기
  • 코드 베이스의 일관성을 따름
  • 향후의 보강의 가능성이 있는가
    • API에 대한 타입 선언: interface
    • 프로젝트 내부에서 사용하는 타입: type

Things to Remember

• Understand the differences and similarities between type and interface.
  • 타입과 인터페이스의 차이점 & 비슷한 점 알기
• Know how to write the same types using either syntax.
  • 각 문법으로 작성하는 법 알기
• Be aware of declaration merging for interface and type inlining for type.
  • 선언 병합과 보강 알기
• For projects without an established style, prefer interface to type for object types.
  • 코드 베이스 스타일이 없으면 => 프로젝트에 어떤 문법을 사용할 지 결정할 때, 일관된 스타일 확립
  • 일관성과 보강의 관점에서 고려

---

아이템 14: 타입 연산과 제너릭 사용으로 반복 줄이기 Use Type Operations and Generic Types to Avoid Repeating Yourself

영문 서적에서는 Item 15

DRY, don't repeat yourself

• 타입의 중복 줄이기
  • 타입에 이름 붙이기
  • 함수 시그니처를 명명된 타입으로 분리하기
  • 인터페이스 확장
  • 타입 간 매핑

타입에 이름 붙이기 named type

interface Point2D {
  x: number;
  y: number;
}
function distance(a: Point2D, b: Point2D) {
  /* ... */
}

함수 시그니처를 명명된 타입으로 분리하기 function signature

type HTTPFunction = (url: string, opts: Options) => Promise<Response>;
const get: HTTPFunction = (url, opts) => {
  /* ... */
};
const post: HTTPFunction = (url, opts) => {
  /* ... */
};

인터페이스 확장 extends interface

interface Person {
  firstName: string;
  lastName: string;
}

interface PersonWithBirthDate extends Person {
  birth: Date;
}

// 또는 type intersectiond를 쓸 수도 있음
type PersonWithBirthDate = Person & { birth: Date };

부분 집합 subset

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

// State을 인덱싱
interface TopNavState {
  userId: State["userId"];
  pageTitle: State["pageTitle"];
  recentFiles: State["recentFiles"];
}

// 매핑된 타입
// 배열의 필드를 루프 돔
type TopNavState = {
  [K in "userId" | "pageTitle" | "recentFiles"]: State[K];
};

// Pick
// type Pick<T, K extends keyof T> = { [P in K]: T[P]; }
type TopNavState = Pick<State, "userId" | "pageTitle" | "recentFiles">;

• Pick은 제너릭 타입이다
  • 함수에서 두 개의 매개변수를 받아서 결과값를 반환하듯, T와 K를 받아서 결과 타입을 반환한다.

예시: 태그를 붙이기 위해 타입을 사용하는 경우

interface SaveAction {
  type: "save";
  // ...
}
interface LoadAction {
  type: "load";
  // ...
}
type Action = SaveAction | LoadAction;
// type ActionType = "save" | "load"; // Repeated types!

type ActionType = Action["type"];
//   ^? type ActionType = "save" | "load"
// 중복 코드 없이 Action을 인덱싱

type ActionRecord = Pick<Action, "type">;
//   ^? type ActionRecord = { type: "save" | "load"; }
// Pick과 인덱싱은 형태가 다름

예시: 생성하고 난 다음 업데이트 되는 클래스

• 타입 대부분이 선택적 필드
  • [k in keyof Options]?: Options[k]
  • 매핑된 타입을 순회하며 Option 내 k 값 속성 찾기 => 각 속성을 optional하게 만들기

interface Options {
  width: number;
  height: number;
  color: string;
  label: string;
}
class UIWidget {
  constructor(init: Options) {}
  update(options: OptionsUpdate) {}
}

// OptionsUpdate 정의하기
// 🚫 중복 코드
interface OptionsUpdate {
  width?: number;
  height?: number;
  color?: string;
  label?: string;
}

// in으로 루프
type OptionsUpdate = { [k in keyof Options]?: Options[k] };

// keyof은? 속성 타입의 유니온 반환
type OptionsKeys = keyof Options;
//   ^? type OptionsKeys = keyof Options
//      (equivalent to "width" | "height" | "color" | "label")

// Partial 패턴
class UIWidget {
  constructor(init: Options) {}
  update(options: Partial<Options>) {}
}

값에 형태에 해당하는 타입 정의

• value to type

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

// typeof은 js의 typeof이 아님
// ts의 typeof: `값`을 읽어서, `타입`을 반환합니다
type Options = typeof INIT_OPTIONS;

• return value to type

// ReturnType 제너릭
type UserInfo = ReturnType<typeof getUserInfo>;

• DRY 원칙을 지칠 때 제네릭이 유용하게 사용됨~!
  • 매개변수 제한

type Pick<T, K extends keyof T> = {
  // extends는 확장이 아닌 부분 집합
  [k in K]: T[k];
};

Things to Remember

• The DRY (don't repeat yourself) principle applies to types as much as it applies to logic.
  • DRY 원칙을 타입에도 최대한 적용
• Name types rather than repeating them. Use extends to avoid repeating fields in interfaces.
  • 타입을 반복하지 말고 name type을 사용하자. field 중복에는 interface extends를 사용하자
• Build an understanding of the tools provided by TypeScript to map between types. These include keyof, typeof, indexing, and mapped types.
  • 매핑을 위해 타입스크립트 도구를 알아두자: keyof, typeof, indexing, and mapped types
• Generic types are the equivalent of functions for types. Use them to map between types instead of repeating type-level operations.
  • 타입 레벨의 반복 코드를 제거하고, 제네릭 타입을 사용하자
  • 제네릭 타입은 타입을 위한 함수와 같다.
• Familiarize yourself with generic types defined in the standard library, such as Pick, Partial, and ReturnType.
  • 표준 라이브러리에 정의된 제네릭 타입을 사용하자 (고생하기 싫으면)
  • Pick, Partial, ReturnType
• Avoid over-application of DRY: make sure the properties and types you're sharing are really the same thing.
  • 중복된 타입의 경우: 기본적으로 서로 다른 속성과 의미를 가질 때는 DRY를 피하기
  • 동일한 유형으로 결합하는 것이 적절하지 않을 수 있다.

---

Item 15: 동적 데이터에 인덱스 시그니처 적용하기: Prefer More Precise Alternatives to Index Signatures

영문 서적에서는 Item 16

인덱스 시그니처 Index Signatures

// [키_이름: 키_타입]: 값_타입
type Rocket = { [속성: string]: string }; // index signature
// - 키 이름으로 무엇이든 가능하기 때문에 자동 완성 x
// - 키마다 다른 타입을 가질 수 없다.

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

• 인덱스 시그니처는 동적 데이터를 표현할 때 사용합니다.
• 동적인 데이터를 표현하고, 객체로 매핑하고, 리턴 값을 단언문을 사용

연관 배열 associative array

• 프로토타입 체인 문제 우회 (아이템 58)

//
interface Row1 {
  [column: string]: number;
}

// 선택적 필드
interface Row2 {
  a: number;
  b?: number;
  c?: number;
  d?: number;
} // Better

// 유니온 타입
type Row3 =
  | { a: number }
  | { a: number; b: number }
  | { a: number; b: number; c: number }
  | { a: number; b: number; c: number; d: number }; // Also better: 번거로움

// Record
type Vec3D = Record<"x" | "y" | "z", number>;
//   ^? type Vec3D = {
//        x: number;
//        y: number;
//        z: number;
//      }

unknown props

interface ButtonProps {
  title: string;
  onClick: () => void;
  [otherProps: string]: unknown; // unknown props
}

renderAButton({
  title: "Roll the dice",
  onClick: () => alert(1 + Math.floor(20 * Math.random())),
  theme: "Solarized", // 추가 props
});

Things to Remember

• Understand the drawbacks of index signatures: much like any, they erode type safety and reduce the value of language services.
  • index signature를 사용하면 any처럼 안정성이 떨어지고, 언어 서비스를 제공 받기 힘들다.
  • undefined를 추가하는 것을 고려한다
• Prefer more precise types to index signatures when possible: interfaces, Map, Records, mapped types, or index signatures with a constrained key space.
  • 더 정확한 타입을 사용하는 것이 좋다: interfaces, Map, Records, mapped types

---

아이템 16: number 인덱스 시그니처보다 Array, 튜플, ArrayLike을 사용하기 Avoid Numeric Index Signatures

영문 서적에서는 Item 17

• 자바스크립트에서 객체란 키/값 쌍의 모음이다.
• 키는 보통 문자열이며, 값은 무엇이든 될 수 있다.

자바스크립트의 객체

• 복잡한 객체를 키로 사용하려 할 때?

• 숫자를 키로 사용하면? 런타임이 문자열로 변환한다.

  const x = { 1: 1 };
  console.log(x); // {"1": 1}
  

• 배열은? 객체다.

  • 숫자 인덱스는? 문자열로 변환되어 사용된다.
  • x["1"] 문자열 키를 사용해서 배열 요소에 접근할 수 있음
  • Object.keys()로 배열의 키를 나열하면? 키는 문자열이다

  let array1 = [1, 2, 3];
  console.log(array1["0"]); // 1
  
  for (const key in array1) {
    console.log(key, array1[key]);
    // "0", 1
    // "1", 2
    // "2", 3
  }
  

for in은 느리다

• 타입이 불확실하다면 for-in 루프는 느리다
  • 객체의 모든 열거 가능한 속성과 프로토타입 체인의 속성까지 검사하므로 느리다
  • 이로 인해 속성 필터링과 순서 유지 등 추가적인 작업이 필요해 성능에 영향을 미친다
• for-of나 for(;;) 루프 사용하기

ArrayLike

• number 타입의 인덱스 시그니처

  • 숫자를 사용해 인덱스 항목을 지정한다면, 숫자 속성에 대한 오해를 일으킬 수 있다

• Array의 타입을 가지지 않은, 어떤 길이를 갖고 있는 배열과 비슷한 형태의 튜플을 사용하고 싶다면?

  • ArrayLike을 사용한다

  // ArrayLike는 숫자 인덱스 시그니처와 length를 가짐
  const tupleLike: ArrayLike<string> = {
    "0": "A",
    "1": "B",
    length: 2,
  }; // OK
  

Things to Remember

• Understand that arrays are objects, so their keys are strings, not numbers. number as an index signature is a purely TypeScript construct designed to help catch bugs.
  • 배열은 객체이므로, 키는 문자열이다.
  • 인덱스 시그니처의 배열[number]에서 number는 버그를 잡기 위한 타입스크립트 코드이다.
• Prefer Array, tuple, ArrayLike, or Iterable types to using number in an index signature yourself.
  • 인덱스 시그니처의 number를 사용하기보다 Array나 튜플, ArrayLike을 사용하자

---

아이템 17 변경 관련된 오류 방지를 위해 readonly 사용하기: Use readonly to Avoid Errors Associated with Mutation

영문 서적에서는 Item 14

• readonly 접근 제어자
  • 변경하지 않는다는 선언

readonly number[]

• readonly number[]는 number[]의 서브타입이다
• 배열의 요소를 읽을 수는 있지만, 쓸 수는 없다
• length를 읽을 수는 있지만, 바꿀 수 없다
• 배열을 변경하는 메서드를 호출할 수 없다

// triangular number 삼각수를 출력하는 코드
// 1, 1+2, 1+2+3, ...

function printTriangles(n: number) {
  const nums = [];
  for (let i = 0; i < n; i++) {
    nums.push(i);
    console.log(arraySum(nums));
  }
}
printTriangles(5);

function arraySum(arr: number[]) {
  let sum = 0;
  for (const num of arr) {
    sum += num;
  }
  return sum;
}

함수 매개변수를 readonly로 선언했을 때

• 타입스크립트는 매개변수가 함수 내에서 변경이 일어나는지 체크한다
• 호출하는 쪽에서 함수가 매개변수를 변경하지 않는다는 보장을 받는다
• 명시적으로 언급하지 않는한, 함수가 매개변수를 변경하지 않는다고 가정하지만, 암묵적인 방법이므로 타입체크에 문제를 일으킬 수 있다
• 단점
  • 함수를 호출하는 다른 함수도 readonly로 변경 => 타입 안정성을 높임
  • 다른 라이브러리에 있는 함수를 호출하는 경우 단언문을 사용해야 하는 경우 단언해야함
• 장점
  • 지역 변수와 관련된 변경 오류 방지

shallow 변경 방지

• 얕은(Shallow) 변경 방지이므로, 중첩된 배열의 내부 값은 여전히 변경할 수 있음 (객체에 적용하는 Readonly 제네릭의 경우도 마찬가지)
• DeepReadonly는? ts-essential 라이브러리. 깊은 readonly 타입
• 인덱스 시그니처에도 readonly 쓸 수 있다

// let obj: {readonly [k: string]: number | string} = {}
let obj: Readonly<{ [k: string]: number | string }> = {};
// obj.hi = "🙌";
obj = { ...obj, hi: "👏" };

Things to Remember

• If your function does not modify its parameters, declare them readonly (arrays) or Readonly (object types). This makes the function's contract clearer and prevents inadvertent mutations in its implementation.
  • 함수가 매개변수를 수정하지 않는다면? readonly array, Readonly object를 적용해 의도치 않은 변경을 방지
• Understand that readonly and Readonly are shallow, and that Readonly only affects properties, not methods.
  • 얕게 동작한다 & 메소드에는 적용되지 않음을 명심
• Use readonly to prevent errors with mutation and to find the places in your code where mutations occur.
  • readonly를 사용해서, 변경하면서 발생하는 오류 방지하고 변경이 발생하는 코드 쉽게 찾기
• Understand the difference between const and readonly: the former prevents reassignment, the latter prevents mutation.
  • const와 readonly 차이점 => const는 재할당x. readonly는 변경을 방지 (재할당... 된다...)

---

아이템 18: 매핑된 타입을 사용하여 값을 동기화하기 Use Record Types to Keep Values in Sync

영문 서적에서는 Item 61

(fail closed) 보수적 접근법 Conservative Approach을 통해 값 변경

• props의 모든 속성을 검사하여 변경이 있는지 확인
• onClick 속성을 제외한 모든 속성의 변경을 감지하는 접근법

function shouldUpdate(oldProps: ScatterProps, newProps: ScatterProps) {
  for (const kStr in oldProps) {
    const k = kStr as keyof ScatterProps;
    if (oldProps[k] !== newProps[k]) {
      if (k !== "onClick") return true;
    }
  }
  return false;
}

(fail open) 실패에 열린 접근법을 통해 값 변경

• 특정 속성만 검사하여 값을 변경하는 방법
• 모든 속성을 검사하지 않기 때문에 예상치 못한 변경이 발생하거나, 변경이 발생하지 않을 수 있음 ("first, do no harm" 원칙에 위배)

function shouldUpdate(oldProps: ScatterProps, newProps: ScatterProps) {
  return (
    oldProps.xs !== newProps.xs ||
    oldProps.ys !== newProps.ys ||
    oldProps.xRange !== newProps.xRange ||
    oldProps.yRange !== newProps.yRange ||
    oldProps.color !== newProps.color
    // (no check for onClick)
  );
}

새로운 속성이 추가될 때 값 변경

• 보수적 접근법과 유사하지만, 타입 체커를 활용하여 타입스크립트가 이를 강제하도록 함
  • 매핑된 타입 REQUIRES_UPDATE 객체를 사용하여 어떤 속성이 변경될 때 업데이트가 필요한지 명시적으로 정의
• 새로운 속성이 추가될 때 자동으로 처리되므로 확장성이 높음

const REQUIRES_UPDATE: Record<keyof ScatterProps, boolean> = {
  xs: true,
  ys: true,
  xRange: true,
  yRange: true,
  color: true,
  onClick: false,
};

function shouldUpdate(oldProps: ScatterProps, newProps: ScatterProps) {
  for (const kStr in oldProps) {
    const k = kStr as keyof ScatterProps;
    if (oldProps[k] !== newProps[k] && REQUIRES_UPDATE[k]) {
      // 매핑된 타입을 통해 타입스크립트가 코드에 제약을 강제하도록 함
      return true;
    }
  }
  return false;
}

Things to Remember

• Recognize the fail open versus fail closed dilemma.
  • 각 접근법에 대한 딜레마 이해
• Use Record types to keep related values and types synchronized.
  • Record type, 매핑된 타입을 사용해 값과 타입을 동기화할 수 있다.
• Consider using Record types to force choices when adding new properties to an interface.
  • 인터페이스에 새로운 속성을 추가할 때, Record type을 사용해 선택을 강제하도록 할 수 있다.

---

english
inadvertent [in·ad·vert·ent]: not resulting from or achieved through deliberate planning.
conservative [con·serv·a·tive] 보수적