📄 Item01 ~ 05

Item01. 타입스크립트와 자바스크립트의 관계 이해하기

• 문법의 유효성과 동작의 이슈는 독립적인 문제이다.
• 타입스크립트는 타입 구문을 통해서 오류의 원인을 추측하는데 큰 도움을 준다.
  • 오류가 어디에서 발생했는지 찾을 수 있고, 해결책도 제시해주는 경우가 있다.
• 모든 자바스크립트는 타입스크립트이지만, 일부 자바스크립트(그리고 타입스크립트)는 체크를 통과한다.
• 타입스크립트에서 오류가 발생하는 근본 원인은 타입스크립트가 이해하는 값의 타입과 실제 값에 차이가 있기 때문이다.

Item02. 타입스크립트 설정 이해하기

• noImplicitAny

  • 변수들이 미리 정의된 타입을 가져야 하는지 여부를 제어
  • 이 옵션이 설정되었다면 명시적으로 : any라고 선언해 주거나 더 분명한 타입을 사용하면 된다.
  • 타입스크립트는 타입 정보를 가질 때 가장 효과적이기 때문에 되도록이면 이 옵션을 true로 설정해야 한다.

• strictNullChecks

  • null, undefined가 모든 타입에서 허용되는지 확인하는 설정
  • 만약 null을 허용하려고 한다면, 의도를 명시적으로 드러냄으로써 오류를 고칠 수 있다.

  const x: number | null = null;
  

  • 만약 null을 허용하지 않으려면, 이 값이 어디서부터 왔는지 찾아야 하고, null을 체크하는 코드나 단언문(assertion)을 추가해야 한다.

  const el = document.getElementById('status');
  el.textContent = 'Ready'; // ~~ 개체가 'null'인 것 같습니다.
  
  if (el) {
    el.textContent = 'Ready'; // null은 제외됨
  }
  
  el!.textContent = 'Ready'; // el이 null이 아님을 단언
  

  • 이 옵션은 null, undefined 관련된 오류를 잡아 내는 데 많은 도움이 되지만, 코드 작성을 어렵게 한다.
  • 이 옵션을 설정 없이 개발하기로 선택했다면 "undefined"는 객체가 아닙니다라는 런타임 오류를 주의해야 한다. 결국은 이 오류 때문에 엄격한 체크를 설정할 수밖에 없다.
  • 그래서 프로젝트가 거대해지기 전에 초반에 설정하는 것이 좋다.

Item03. 코드 생성과 타입이 관계없음을 이해하기

• 타입스크립트 컴파일러의 역할
  • 최신 TS/JS를 브라우저에서 동작할 수 있도록 구버전의 JS로 트랜스파일함
  • 코드의 타입 오류를 체크함

---

⭐️ 타입 오류가 있는 코드도 컴파일이 가능하다

• 컴파일은 타입 체크와 독립적으로 동작하기 때문에, 타입 오류가 있는 코드도 컴파일이 가능하다.
  • 문제가 될 만한 부분을 알려 주지만, 그렇다고 빌드를 멈추지는 않는다.
• 만약 오류가 있을 때 컴파일하지 않으려면, tsconfig.json에 noEmitOnError 옵션을 설정하거나 빌드 도구에 동일하게 적용하면 된다.

⭐️ 런타임에는 타입 체크가 불가능하다

• 실제로 자바스크립트로 컴파일되는 과정에서 모든 인터페이스, 타입, 타입 구문을 그냥 제거되어 버린다.
• 런타임 시점에 타입 정보를 유지하는 방법
  • instanceof 대신에 특정 속성이 존재하는지 in을 통해 확인
  • 런타임에 접근 가능한 타입 정보를 명시적으로 저장하는 '태그' 기법
  • 타입(런타임 접근 불가)과 값(런타임 접근 가능)을 둘 다 사용하는 기법
    • 인터페이스는 타입으로만 사용 가능하지만, 클래스는 타입과 값으로 모두 사용할 수 있으므로 오류가 발생하지 않는다.

⭐️ 타입 연산은 런타임에 영향을 주지 않는다

function asNumber(val: number | string): number {
  return val as number;
}

function asNumber(val) {
  return val;
}

• 위 예시는 string 또는 number 타입인 값을 항상 nubmer로 정제하는 코드이다.
  • 변한된 자바스크립트 코드를 보면 코드에 아무런 정제 과정이 없다.
  • as number는 타입 연산이고 런타임 동작에는 아무런 영향을 미치지 않는다.
  • 그래서 값을 정제하기 위해서는 런타임의 타입을 체크해야 하고 자바스크립트 연산을 통해 변환을 수행해야 한다.

function asNumber(val: number | string): number {
  return typeof(val) === 'string' ? Number(val) : val;
}

⭐️ 런타임 타입은 선언된 타입과 다를 수 있다

• 아래 코드에서 마지막의 console.log까지 실행될 수 있는지 생각해보자.

function setLightSwitch(value: boolean) {
  switch (value) {
    case true:
      turnLightOn();
      break;
    case false:
      turnLightOff();
      break;
    default:
      console.log('실행되지 않을까 봐 걱정됩니다.');
  }
}

interface LightApiResponse {
  lightSwitchValue: boolean;
}

async function setLight() {
  const response = await fetch('/light');
  const result: LightApiResponse = await response.json();
  setLightSwitch(result.lightSwitchValue);
}

• setLightSwitch 함수의 인자에 : boolean이라는 타입 선언문이 있는데 이는 런타임시 제거된다.
  • 자바스크립트였다면 실수로 string 값으로 호출할 수도 있었을 것이다.
  • 물론 타입스크립트에서도 API를 잘못 파악해서 lightSwitchValue가 실제로 문자열이였다면, 런타임에는 setLightSwitch 함수까지 전달될 것이다.
  • 또는 배포된 후에 API가 변경되어 lightSwitchValue가 문자열이 되는 경우도 있다.
• 이와 같이 타입스크립트에서는 런타임 타입과 선언된 타입이 맞지 않을 수 있다.
  • 타입이 달라지는 혼란스러운 상황을 가능한 한 피해야 한다.
  • 선언된 타입이 언제든지 달라질 수 있다는 것을 명심해야 한다.

⭐️ 타입스크립트 타입으로는 함수를 오버로드할 수 없다

• 함수 오버로딩

  // 아래 두 함수는 중복된 함수 구현이다.
  function add(a: number, b: number) { return a + b; }
  function add(a: string, b: string) { return a + b; }
  

  • 동일한 이르메 매개변수만 다른 여러 버전의 함수를 허용
  • 그러나 타입스크립트에서는 타입과 런타임의 동작이 무관하므로 함수 오버로딩은 불가능하다.

• 타입스크립트가 함수 오버로딩 기능을 지원하기는 하지만, 온전히 타입 수준에서만 동작한다.

  • 하나의 함수에 대해 여러 개의 선언문을 작성할 수 있지만, 구현체는 오직 하나뿐이다.
  • 타입스크립트에서 함수 오버로딩 기능을 동작하게 하려면 오버로팅 타입 보다는 조건부 타입을 사용하는 것이 좋다.

⭐️ 타입스크립트 타입은 런타임 성능에 영향을 주지 않는다.

• 타입과 타입 연산자는 자바스크립트 변환 시점에 제거되기 때문에, 런타임의 성능에 아무런 영향을 주지 않는다.
  • 타입스크립트의 정적 타입은 실제로 비용이 전혀 들지 않는다.

Item04. 구조적 타이핑에 익숙해지기

• 덕 타이핑(Duck Typing)

  • 객체가 어떤 타입에 부합하는 변수와 메서드를 가질 경우 객체를 해당 타입에 속하는 것으로 간주하는 방식
  • 자바스크립트는 본질적으로 덕 타이핑 기반이다.

• 타입스크립트도 구조적 타이핑(덕 타이핑) 기반인데 이 때문에 값을 세밀하게 구분하지 못하는 경우가 있다.

  • 그래서 값을 구분하기 위해 공식 명칭이 필요하다면 상표를 붙이는 것을 고려해야 한다.

• 타입이 열려있다

  • 타입의 확장에 열려 있다는 의미
  • 즉, 타입에 선언된 속성 외에 임의의 속성을 추가하더라도 오류가 발생하지 않는다는 것

• 타입스크립트 타입 시스템에서 타입은 열려있는데 이러한 특성 때문에 가끔 당황스러운 결과가 발생한다.

interface Vector3D {
  x: number;
  y: number;
  z: number;
}

function calculateLengthL1(v: Vector3D) {
  let length = 0;
    
  for (const axis of Object.keys(v)) {
    const coord = v[axis]; // 'string'은 'Vector3D'의 인덱스로 사용할 수 없기에 엘리먼트는 암시적으로 'any' 타입입니다.
      
    length += Math.abs(coord);
  }
    
  return length;
}

• 위와 같은 경우 axis는 Vector3D 타입인 v의 키 중 하나이기 때문에 x, y, z 중 하나여야 한다.
  • 그리고 Vector3D의 선언에 따르면 이들은 모두 number이므로 coord의 타입이 number가 되어야 할 것으로 예상되지만 위와 같이 오류가 뜨는 것이 맞다.
  • v는 어떤 속성이든 가질 수 있기 때문에 axis의 타입은 string이 될 수도 있다.
  • 정확한 타입으로 객체를 순회하는 것을 까다로운 문제이다.
  • 그래서 루프보다는 모든 속성을 각각 더하는 구현이 더 낫다.

function calculateLengthL1(v: Vector3D) {
  return Math.abs(v.x) + Math.abs(v.y) + Math.abs(v.z);
}

Item05. any 타입 지양하기

• any 타입에는 타입 안전성이 없다.
• any는 함수 시그니처를 무시해 버린다.
  • 호출하는 쪽은 약속된 타입의 입력을 제공하고, 함수는 약속된 타입의 출력을 반환한다.
  • 그러나 any 타입을 사용하면 이러한 약속을 어길 수 있다.
• any 타입에는 언어 서비스가 적용되지 않는다.
  • 어떤 심벌에 타입이 있다면 타입스크립트 언어 서비스는 자동완성 기능과 적절한 도움말을 제공한다.
  • 그러나 any 타입인 심벌을 사용하면 아무런 도움을 받지 못한다.
• any 타입은 코드 리팩토링 때 버그를 감춘다.
• any는 타입 설계를 감춰버린다.
  • any 타입을 사용하면 타입 설계가 불분명해진다.
  • 설계가 잘 되었는지, 설계가 어떻게 되어 있는지 전혀 알 수 없다.
  • 설계가 명확히 보이도록 타입을 일일이 작성하는 것이 좋다.
• any는 타입시스템의 신뢰도를 떨어뜨린다.