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

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

---

아이템 43: 몽키 패치보다는 안전한 타입을 사용하기 Prefer Type-Safe Approaches to Monkey Patching

• 자바스크립트의 특징 중 하나: 객체와 클래스에 임의의 속성을 추가할 수 있다.
• 유연하다.
  • window, document에 전역 변수 만들기
  • const el = document.getElementById('colobus'); el.home = 'tree';
  • 프로토타입에도 추가할 수 있다.
    • 프로토타입에 속성을 추가하면 해당 속성이 모든 인스턴스에 상속되어 버림

    RegExp.prototype.monkey = "Capuchin";
    /123/.monkey;
    

전역 객체 추가하기

document.monkey = "Tamarin";
//       ~~~~~~ Property 'monkey' does not exist on type 'Document'
(document as any).monkey = "Tamarin"; // 정상! 하지만 안전하지 않다.

document.addEventListener("DOMContentLoaded", async () => {
  const response = await fetch("/api/users/current-user");
  const user = (await response.json()) as User;
  window.user = user; // OK
});

// ... elsewhere ...
export function greetUser() {
  alert(`Hello ${window.user.name}!`); // OK
}

어떻게 할까? A. 보강!

// TypeScript에서 Document 인터페이스를 선언하고 monkey 속성을 추가
interface Document {
  monkey: string;
}

// ### 글로벌 범위에서 Document 인터페이스를 보강
// Document 인터페이스를 확장하여 전역 document 객체에 monkey 속성을 추가할 수 있도록 한다.
// ESModule 관점에서 제대로 동작하려면 global 선언이 있어야 한다.

// ### 모듈 스코프와 글로벌 스코프의 차이
// ESModules에서는 각 모듈이 자체적인 스코프를 가지므로, 전역 객체에 속성을 추가하려면 이를 명시적으로 선언해야 한다.
declare global {
  interface Document {
    monkey: string;
  }
}

document.monkey = "Tamarin";

장점

• 타입이 더 안전하다. (오타, 잘못된 할당)
• 속성에 주석을 붙일 수 있다.
• 속성에 자동 완성을 사용할 수 있다.
• 몽키 패치가 어떤 부분에 적용되었는지 정확한 기록이 남는다.

단점

• 보강은 전역적으로 적용되어, 코드의 다른 부분이나 라이브러리로부터 분리할 수 없다. (큰 단점)
• 애플리케이션이 실행되는 동안에 속성을 할당하면, 실행 시점에 보강을 적용할 수 없다. HTMLElement들을 조작할 경우 어떤 속성이 있거나 없다면 문제가 된다. string | undefined로 선언할 경우 불편해진다.

declare global {
  interface Window {
    /** The currently logged-in user */
    user: User | undefined;
  }
}

// ...
export function greetUser() {
  alert(`Hello ${window.user.name}!`);
  //             ~~~~~~~~~~~ 'window.user' is possibly 'undefined'.
}

B. 구체적인 타입 단언문

• 확장해서 단언하는 경우! 👏

type MyWindow = typeof window & {
  /** The currently logged-in user */
  user: User | undefined;
};
// 타입 단언문은 정상이고, 할당문의 타입은 안전하다.
// Document 타입을 건드리지 않고, 별도로 확장하는 새로운 타입을 도입
// 모듈 영역 문제가 해결되었다. (import하는 곳의 영역만 해당됨)
// 하지만~ 몽키 패치를 남용해서는 아니되며, 궁극적으로 더 잘 설계된 구조로 리팩터링하는 것이 좋습니다.

document.addEventListener("DOMContentLoaded", async () => {
  const response = await fetch("/api/users/current-user");
  const user = (await response.json()) as User;
  (window as MyWindow).user = user; // OK
});

// ...
export function greetUser() {
  alert(`Hello ${(window as MyWindow).user.name}!`);
  //             ~~~~~~~~~~~~~~~~~~~~~~~~~ Object is possibly 'undefined'.
}

Things to Remember

• Prefer structured code to storing data in globals or on the DOM.
  • 전역 변수나 DOM에 데이터를 저장하지 않고, 데이터를 분리해서 사용하는 것을 지향하자.
• If you must store data on built-in types, use one of the type-safe approaches (augmentation or asserting a custom interface).
  • 내장 타입에 데이터를 저장해야 하는 경우, 안전한 타입 접근법 중 하나를 사용한다. (보강 augmentation, 사용자 정의 인터페이스 단언 assering a custom interface)
• Understand the scoping issues of augmentations. Include undefined if that's a possibility at runtime.
  • 모듈 영역 문제를 이해하자. 런타임에 undefined일 가능성이 있다면? 포함하자.

아이템 44: 타입 커버리지를 추적하여 타입 안정성 유지하기 Item 49: Track Your Type Coverage to Prevent Regressions in Type Safety

명시적 any 타입

• any 타입을 좁히기 위해 명시적으로 사용한 any는, 인덱스를 생성하면 단순 any가 되어 코드 전반을 오염시킴
  • any[], {[key:string]:any}, Record<string, any>
• 그렇다면 결국 왜 쓰는 것?? unknown을 사용하는 것이 좋겠다.

서드파티 any 타입 선언

• @types 선언 파일로부터 any 타입이 전파되기 때문에, 코드 전반에 영향을 미친다.
  • noImplicitAny를 설정하고, any 작성한 적 없더라도 마찬가지~

any 케이스

// A. 어떤 종류의 column 정보를 만드는 함수
function getColumnInfo(name: string): any {
  return utils.buildColumnInfo(appState.dataSchema, name); // Returns any
}

// B. 타입 정보가 모두 제거된 상태
// ❗️ 예제 코드 확인이 안됨
// ❌ myModule.d.ts 가 없으면 오류

declare module "my-module";
//              ~~~~~~~~~~ Invalid module name in augmentation, module 'my-module' cannot be found.

// ❌ 실제로 존재하는 라이브러리를 declare 시, 타입 체커가 일함
declare module "@next/mdx";
import { notMethod } from "@next/mdx";
//       ~~~~~~~~~ Module '"@next/mdx"' has no exported member 'notMethod'
notMethod();

// ❌ myModule.d.ts가 있으면 타입 체커가 일함.
// myModule.d.ts
declare module "my-module" {
  export function someMethod(): void;
}
// 다른 파일
declare module "my-module";
import { someMethod, notMethod } from "my-module";
//                   ~~~~~~~~~ Module '"my-module"' has no exported member 'notMethod'.
someMethod();
notMethod();

// C. 타입에 버그가 있는 경우
// 유니온 타입을 반환하도록 선언하고, 실제로는 특정한 값을 반환하는 경우
// 선언된 타입과 실제 반환된 타입이 맞지 않는 경우?
// any로 단언문을 사용해야 한다.

npx type-coverage any의 갯수를 추적하기

• 터미널에서 percentage(백분율)를 확인할 수 있는 라이브러리

$ npx type-coverage --detail // any 타입을 모두 출력하는 옵션

• any가 더 이상 필요 없거나, 실행되지 않는 코드일 수도 있으므로 꾸준히 타입 커버리지를 추적하여 점검하는 것이 좋음

Things to Remember

• Even with noImplicitAny set, any types can make their way into your code either through explicit anys or third-party type declarations (@types).
  • noImplicitAny가 설정되어 있어도 명시적 any, 서드파티 타입 선언을 통해 코드 내에 존재할 수 있다.
• Consider tracking how well-typed your program is using a tool like type-coverage. This will encourage you to revisit decisions about using any and increase type safety over time.
  • 작성한 프로그램의 타입이 얼마나 잘 선언되었는 지 추적함으로서 => any의 사용을 줄여나가며 타입 안정성을 높일 수 있다.
    • 추적 라이브러리 예시: type-coverage

// 영어
augmentation 보강