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

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

---

아이템 58: 모던 자바스크립트 작성하기 이어서

프로토타입 대신 클래스 사용하기

• ES6 class 키워드(클래스 기반 모델) 도입 이전 => 프로토타입 기반의 객체 모델을 사용했다.
  • 마이그레이션 대상 코드에 프로토타입이 있다면 클래스로 바꾸는 것이 좋다. 직관적이고 간결함.
• VS Code에는 TypeScript를 위한 유용한 리팩토링 기능이 포함되어 있습니다. 예를 들어, 함수 추출 및 상수 추출 기능이 있습니다. 추출하고자 하는 소스 코드를 선택한 다음, 좌측에 나타나는 전구 아이콘을 클릭하거나 (⌘.)를 눌러 사용 가능한 리팩토링 옵션을 확인할 수 있습니다.

  https://code.visualstudio.com/Docs/languages/typescript#_refactoring

// 클래스
function Person(first, last) {
  // 함수명 아래 ...이 나타나야 하는데 안 나타남
  this.first = first;
  this.last = last;
}

Person.prototype.getName = function () {
  return this.first + " " + this.last;
};

// 프로토타입
class Person {
  first: string;
  last: string;

  constructor(frist: string, last: string) {
    this.first = first;
    this.last = last;
  }

  getName() {
    return this.first + " " + this.last;
  }
}

const marie = new Person("Marie", "Curie");
const personName = marie.getName();

var 대신 let/const 사용하기

• var를 let, const로 변경 시 일부 코드에서 TS 오류가 발생할 수 잇는데, 스코프 문제가 생길 수 있는 코드이니 수정하면 된다.
• 중첩 함수 구문에도 var의 경우와 비슷한 스코프 문제가 존재
  • 함수 호이스팅은 실행 순서를 예상하기 어렵게 만들고 직관적이지 않기 때문에 함수 선언식 대신 표현식을 쓰자는 의견

for(;;) 대신 for-of 또는 배열 메서드 사용하기

• C 스타일의 for 루프: for(;;)
• 모던 자바스크립트의 for-of 루프
  • for-of 루프는 코드가 짧고 인덱스 변수를 사용하지도 않기 때문에 실수를 줄일 수 있습니다.
  • 인덱스 변수가 필요하다? forEach 메서드를 사용할 수 있습니다.

함수 표현식보다 화살표 함수를 사용하기

• 일반 표현식 함수의 this 바인딩은 non-strict mode에서는 window, strict mode에서는 undefined다.
• 화살표 함수는 정의된 환경의 this를 유지한다. == 일관된 this 바인딩. 콜백 함수 내에서 this를 사용해야 하는 경우, 화살표 함수를 사용하자.
• noImplicitThis를 설정하면? this 바인딩 관련 오류를 표시해준다.

class Foo {
  method() {
    console.log(this);
    [1, 2].forEach(function (i) {
      console.log(this); // noImplicitThis 오류 발생: 'this' implicitly has type 'any' because it does not have a type annotation.
    });
  }
  arrow() {
    console.log(this);
    [1, 2].forEach((i) => {
      console.log(this);
    });
  }
}
const f = new Foo();
f.method();
// strict 모드: Foo, undefined, undefined
// non-strict 모드: Foo, window, window
f.arrow();
// 항상 Foo, Foo, Foo

단축 객체 표현 compact object literal 과 구조 분해 할당 object de-structuring 사용하기

• { x: x }를 { x }와 같이 표현
  • 가독성이 좋고 실수가 적다.
• 화살표 함수 내에서 객체를 반환할 때는 소괄호로 감싸야 함 => 함수의 구현부에는 블록이나 단일 표현식이 필요하기 때문에, 소괄호로 감싸서 표현식으로 만드는 것이다.

["A", "B"].map((char, idx) => ({ char, idx }));
// [{char: "A", idx: 0}, {char: "B", idx: 1}]

• 객체의 속성 중 함수를 축약해서 표현하는 방법

const obj = {
  onClickLong: function (e) {
    // ...
  },
  onClickCompact(e) {
    // .. 축약 표현!
  },
};

• 객체 구조 분해

const { props } = obj;
const { a, b } = props;

// 이렇게 줄일 경우 a와 b는 변수로 선언되지만, props는 변수 선언이 아님에 주의
const {
  props: { a, b },
} = obj;

// 구조 분해 문법 내에서 기본값을 지정할 수 있음
const { a = "default" } = obj.props;

// 튜플처럼 사용하는 배열에서 유용
const point = [1, 2, 3];
const [x, y, z] = point; // 변수에 할당
const [, a, b] = point; // 첫 번째 요소는 무시하는 경우

// 함수 매개변수에도 사용할 수 있습니다
const points = [
  [1, 2, 3],
  [4, 5, 6],
];
points.forEach(([x, y, z]) => console.log(x + y + z)); // 6, 15

함수 매개변수 기본값 사용하기

• 자바스크립트에서 함수의 모든 매개변수는 선택적이며, 매개변수를 지정하지 않으면 undefined로 간주됩니다.

function log2(a, b) {
  console.log(a, b);
}
log2(); // undefined undefined

• 매개변수에 기본값을 지정하면 코드가 간결해질 뿐만 아니라, 선택적 매개변수라는 것을 명확히 나타내는 효과도 줄 수 있습니다. 기본값을 기반으로 타입 추론이 가능하기 때문에, 마이그레이션할 때 매개변수에 타입구문을 쓰지 않아도 됩니다.

// 옛날 방식
function paserNum(str, base) {
  base = base || 10;
  return parseInt(str, base);
}

// 모던 자바스크립트
function parseNum(str, base = 10) {
  return parseInt(str, base);
}

저수준 프로미스나 콜백 대신 async/await 사용하기

• async와 await을 사용하면 코드가 간결해져서 버그나 실수를 방지할 수 있고, 비동기 코드에 타입 정보가 전달되어 타입 추론을 가능하게 합니다.

// callback과 프로미스
function getJSON(url: string) {
  return fetch(url).then((response) => response.json());
}
function getJSONCallback(url: string, cb: (result: unknown) => void) {
  // ...
}

// async/await
async function getJSON(url: string) {
  const response = await fetch(url);
  return response.json();
}

연관 배열에 객체 대신 Map과 Set 사용하기

function countWords(text: string) {
  const counts: { [word: string]: number } = {};
  for (const word of text.split(/[\s,.]+/)) {
    counts[word] = 1 + (counts[word] || 0);
  }
  return counts;
}

• constructor의 초기값은 Object.prototype에 있는 생성자 함수이다.
• 객체의 프로토타입 체인에서 상속된 속성들이 예상치 않은 동작을 유발
  • 방지하기 위해 Map을 사용할 수 있다.

function countWordsMap(text: string) {
  const counts = new Map<string, number>();
  for (const word of text.split(/[\s,.]+/)) {
    counts.set(word, 1 + (counts.get(word) || 0)); // 객체의 키가 문자열로 제한
  }
}

• 결과
  • Object.prototype의 속성들과 충돌할 위험이 없다. Map은 순서를 보장하고, 성능 면에서도 더 효율적

타입스크립트에 use strict 넣지 않기

• ES5에서는 버그가 될 수 있는 코드 패턴에 오류를 표시해주는 '엄격 모드(strict mode)'가 도입됨
  • TS의 안정성 검사 sanity check가 엄격 모드보다 훨씬 엄격하다. (무의미)
• alwaysStrict 또는 strict 옵션을 설정하면? 엄격 모드로 코드를 파싱하고, 생성된 자바스크립트에 'use strict'을 추가합니다.

TC39, JS 표준화 단계

• TC39는 매년 새로운 기능을 발표하고 있고, 자바스크립트의 표준화 4단계 중 3단계 이상의 기능들을 타입스크립트 내에 구현하고 있습니다.

Stage 0: Strawman

아이디어가 제안되고 논의되는 초기 단계입니다. 아직 공식적인 제안이 아니며, 아이디어 수준에서 논의됩니다.

Stage 1: Proposal

제안이 공식적으로 TC39에 제출되고, 명확한 문제 정의와 솔루션이 포함됩니다. 제안이 발전할 수 있는 구조를 가지며, 피드백을 받아 개선됩니다.

Stage 2: Draft

제안이 좀 더 구체화되고, 구체적인 문서와 예제가 포함됩니다. 이 단계에서는 제안이 실제로 구현될 가능성이 높아집니다. 타입스크립트는 이 단계부터 새로운 기능을 실험적으로 구현하기 시작할 수 있습니다.

Stage 3: Candidate

제안이 거의 완성된 상태로, 리뷰와 피드백을 통해 최종 조정이 이루어집니다. 이 단계의 제안은 대부분의 경우 표준으로 채택됩니다. 타입스크립트는 이 단계의 기능을 적극적으로 구현하여 사용자에게 제공합니다.

Stage 4: Finished

제안이 최종적으로 승인되어 표준에 포함됩니다. 이 단계의 기능은 공식 ECMAScript 사양의 일부가 됩니다.

요약

• TS 개발 환경은 모던 자바스크립트도 실행할 수 있으므로, 최신 기능들을 적극적으로 사용한다. 코드 품질을 향상시킬 수 있고 타입스크립트의 타입 추론이 나아진다.
• 타입스크립트 개발 환경에서 컴파일러와 언어 서비스를 사용해 class, 구조 분해, async/await 기능을 쉽게 배울 수 있다.
• 'use strict'는 타입스크립트 컴파일러 수준에서 사용되므로 코드에서 제거
• TC39 깃헙 저장소, 타입스크립트의 릴리스 노트를 통해 최신 기능을 확인할 수 있다.

아이템 59: 타입스크립트 도입 전에 @ts-check와 JSDoc을 시험해 보기

@ts-check

• @ts-check 지시자를 사용하면, 타입스크립트 전환시에 어떤 문제가 발생하는지 미리 시험해 볼 수 있습니다.
  • 타입 체커가 파일을 분석하고, 발견된 오류를 보고하도록 지시함 - 매우 느슨한 수준으로 타입 체크 수행하는데, noImplicitAny 설정을 해제한 것보다 체크를 덜 함

type.d.ts: 프로젝트 타입 선언

• 선언되지 않은 전역 변수

// @ts-check
/// <reference path="./type.d.ts">
console.log(user.firstName);

// type.d.ts
interface UserData {
  firstName: string;
  lastName: string;
}
declare let user: UserData;

서드파티 라이브러리

• @ts-check 지시자를 사용하면서, 서드파티의 라이브러리의 타입 선언을 설치 & 활용해서 타입 체크를 시험해볼 수 있다.

DOM 엘리먼트와 JSDoc

• DOM 엘리먼트 관련 오류
  • 타입 단언, 리턴 타입 정의 등 TS 기능이기 때문
  • JSDoc을 사용하여 타입 단언을 대체할 수 있다.

// @ts-check
const ageEl = /** @type {HTMLInputElement} */ document.getElementById("age");
ageEl.value = "12";

부정확한 JSDoc

• 이미 JSDoc 스타일의 주석을 사용 중이었다면, @ts-check 지시자를 설정하는 순간부터 기존 주석에 타입 체크가 동작하게 되고 + 오류 발생
  • 오류를 확인하고 수정
• Infer parameters types from usage
• JS일 때
• TS일 때
• 잘 동작하지 않는 경우도 있고, 주석이 코드 분량을 늘려서 로직을 해석하는데 방해가 될 수 있습니다.
• 타입스크립트는 ts에서 가장 잘 동작한다. 마이그레이션의 목표 => ts
• 다만, 이미 JSDocs 주석으로 타입 정보가 많이 담겨있는 코드라면? @ts-check 지시자로 타입 체커를 실험해서 초기 오류를 빠르게 잡을 수 있다.

요약

• 파일 상단에 // @ts-check를 추가하여 자바스크립트에서도 타입 체크를 수행할 수 있다.
• 전역 선언과 서드파티 라이브러리의 타입 선언을 추가하는 방법을 익힐 수 있음
• JSDoc 주석을 잘 활용하면? JS에서도 타입 단언과 추론 할 수 있음
• JSDoc은 중간 단계다.

아이템 60: allowJs로 TS와 JS 같이 사용하기

• allowJS 옵션을 사용하면, TS와 JS를 서로 import할 수 있다.
  • TS는 JS의 상위 집합이다~
  • 모듈 단위로 타입스크립트로 전환하면서, 테스트 수행해야하기 때문에 allowJs 옵션이 필요
• 번들러에 TS가 통합되어 있거나, 플러그인 방식으로 통합이 가능하다면? allowJs 간단히 적용 가능
• tsify, browserify

  $ browserify index.ts -p [ tsify --allowJs ] > bundle.js
  

• jest.conifg.js

  module.exports = {
    transform: {
      "^.+\\.tsx?$": "ts-jest", // 전달할 타입스크립트 소스 지정
    },
  };
  

• outDir 옵션
  • 타입스크립트가 outDir에 지정된 디렉토리에 소스 Dir과 비슷한 구조로 자바스크립트 코드를 생성하게 됨 => outDir로 지정된 디렉토리를 대상으로 기존 빌드 체인을 실행하면 됨
  • 기존 자바스크립트 규칙(target, module 옵션)에 따라 출력 옵션을 조정해야 할 수 있음

Things to Remember

• Use the allowJs compiler option to support mixed JavaScript and TypeScript as you transition your project.
  • 점진적 마이그레이션을 위해, 자바스크립트와 타입스크립트를 동시에 사용할 수 있는 allowJs 옵션 사용
• Get your tests and build chain working with TypeScript before beginning large-scale migration.
  • 대규모 마이그레이션 전에, 테스트와 빌드 체인에 타입스크립트를 적용한다.

아이템 61: 의존성 관계에 따라 모듈 단위로 전환하기

• 점진적 마이그레이션
  • 모듈 단위로 진행
• 모듈 간 의존성 문제!
  • 다른 모듈에 의존하지 않는 최하단 모듈부터 작업을 시작해야 한다.
• 서드파티 라이브러리
  • 프로젝트 --의존--> 서드파티 라이브러리
  • 서드파티 라이브러리 --의존x--> 프로젝트
  • 서드파이 라이브러리 타입 정보를 먼저 해결한다.
• 외부 API의 타입 정보도 먼저 해결한다.
  • 외부 API의 타입 정보는 문맥이 없기 때문에, 타입스크립트가 추론하기 어렵다.
  • API 사양을 기반으로 타입 정보를 생성해야 한다.

의존성

• dependency graph를 그려볼 수 있다.
  • 화살표: 의존성
  • 짙은 상자: 순환 의존성 circular dependency
• 대부분의 프로젝트에서 의존성 최하단에 유틸리티 모듈이 위치하는 패턴!
• 마이그레이션할 때는? 타입 정보만 추가하고, 리팩토링을 하면 안된다.
  • 리팩토링 사항은 목록화 하기

선언되지 않은 클래스 멤버

• 클래스 멤버를 명시적으로 선언하기 위해서, IDE의 quick fix 기능을 사용할 수 있습니다.
  • Declare property '~~'
  • Add all missing members

class Greeting {
  constructor(name) {
    this.greeting = "Hello";
    //   ~~~~~~~~ Property 'greeting' does not exist on type 'Greeting'
    this.name = name;
    //   ~~~~ Property 'name' does not exist on type 'Greeting'
  }
  greet() {
    return `${this.greeting} ${this.name}`;
    //             ~~~~~~~~         ~~~~ Property ... does not exist
  }
}

• 잘못된 설계
  • 리팩토링 하지 않습니다!
  • 발견하면 기록하기

타입이 바뀌는 값

• 한꺼번에 객체를 생성하기

// js => ts
const state = {};
state.name = "New York";
//    ~~~~ Property 'name' does not exist on type '{}'
state.capital = "Albany";
//    ~~~~~~~ Property 'capital' does not exist on type '{}'

// ts
const state = {
  name: "New York",
  capital: "Albany",
}; // OK

// 임시방편 단언문
// 마이그레이션이 완료된 이후, 문제를 제대로 해결해야 한다!
interface State {
  name: string;
  capital: string;
}
const state = {} as State;
state.name = "New York"; // OK
state.capital = "Albany"; // OK

• JSDoc과 @ts-check를 사용해 타입 정보를 추가한 상태라면, TS로 전환하는 순간 타입 정보가 '무효화'된다는 것에 주의 (ts에서 동작하지 않음)
  • Annotate with type from JSDoc
    • JSDoc을 사용해 타입 구문을 생성한 후, JSDoc 삭제!
• 마지막 단계: 테스트 코드를 타입스크립트로 전환
  • 테스트 코드는 의존성 관계도의 최상단에 위치. 마이그레이션의 마지막 단계

Things to Remember

• Start migration by adding @types for third-party modules and external API calls.
  • 마이그레이션의 시작 => 서드파티 모듈과 외부 API콜
• Begin migrating your own modules from the bottom of the dependency graph upwards. The first module will usually be some sort of utility code. Consider visualizing the dependency graph to help you track progress.
  • 의존성 관계도의 아래부터 위로 올라가며 마이그레이션 한다. bottom to top~
  • 최하단은 보통 유틸리티 코드다. 의존성 관계도를 시각화하면서 진행 과정을 추적하는 것이 좋다.
• Resist the urge to refactor your code as you uncover odd designs. Keep a list of ideas for future refactors, but stay focused on TypeScript conversion.
  • 이상한 설계를 발견해도 리팩터링 금지. 마이그레이션에 집중한다. 리팩터링 재료는 목록으로 만든다.
• Be aware of common errors that come up during conversion. Move JSDoc types into TypeScript type annotations if necessary to avoid losing type safety as you convert.
  • 필요에 따라 JSDoc 타입을 타입 구문으로 변경한다. 타입스크립트로 전환하며 발견하는 일반적 오류를 놓치지 않도록 한다.

아이템 62: 마이그레이션의 완성을 위해 noImplicitAny 설정하기

• noImplicitAny를 설정하여 마이그레이션 완료
  • 처음에는 로컬에만 옵션 설정하고 작업 (원격에 설정하지 않으면 빌드 실패가 안뜨기 때문)
  • 수정한 부분만 커밋해서 점진적 마이그레이션 하기!
• 타입 체커가 발생하는 오류의 개수 => noImplicitAny와 관련된 작업의 진척을 나타내는 지표로 활용
• 타입 체크의 강도 서서히 높이기
  • strictNullChecks => noImplicitAny => strict

Things to Remember

• Don't consider your TypeScript migration done until you adopt noImplicitAny. Loose type checking can mask real mistakes in type declarations.
  • noImplictAny 설정을 활성화하여 마이그레이션의 마지막 단계를 진행한다.
  • noImplictAny 설정이 없다면? 타입 선언과 관련된 실제 오류가 드러나지 않는다.
• Fix type errors gradually before enforcing noImplicitAny. Give your team a chance to get comfortable with TypeScript before adopting stricter checks.
  • noImplictAny를 전면 적용하기 전에, 타입 오류를 점진적으로 수정한다.
  • 엄격한 타입 체크를 적용하기 전에 팀원들이 타입스크립트에 익숙해질 수 있도록 한다.