이펙티브 타입스크립트 4장 & 5장

[sbyeol3]

아이템 34. 부정확한 타입보다는 미완성 타입을 사용하기

• 타입 선언의 정밀도를 높일 때는 주의를 기울여야 한다. 실수가 발생하기 쉽고 잘못된 타입은 타입이 없는 것보다 못할 수 있다.
• 어설프게 완벽을 추구하려다가 오히려 역효과가 발생할 수 있다.
• any와 unknown을 구별해서 사용하자.

아이템 35. 데이터가 아닌, API와 명세를 보고 타입 만들기

• 코드의 구석 구석까지 타입 안전성을 얻기 위해 API 또는 데이터 형식에 대한 타입 생성을 고려해야 한다.
• 데이터에 드러나지 않는 예외적인 경우들이 문제가 될 수 있으므로 데이터보다는 명세로부터 코드를 생성하는 것이 좋다.

아이템 36. 해당 분야의 용어로 타입 이름 짓기

• 엄선된 타입, 속성, 변수의 이름은 의도를 명확히 하고 코드와 타입의 추상화 수준을 높인다. 잘못 선택한 타입 이름은 코드의 의도를 왜곡하고 잘못된 개념을 심어준다.
• 코드로 표현하고자 하는 모든 분야에는 주제를 설명하기 위한 전문 용어들이 있다. 해당 분야에 이미 존재하는 용어를 사용해야 한다.
• 같은 의미에 다른 이름을 붙이지 말자.

아이템 37. 공식 명칭에는 상표를 붙이기

• 상표 기법은 타입 시스템에서 동작하지만 런타임에 상표를 검사하는 것과 동일한 효과를 얻을 수 있다.
• 타입스크립트는 구조적 타이핑을 사용하기 때문에 값을 세밀하게 구분하지 못하는 경우가 있다.

아이템 38. any 타입은 가능한 한 좁은 범위에서만 사용하기

function f1() {
  const x: any = expressionReturingFoo();
  processBar(x);
}

function f2() {
  const x = expressionReturingFoo();
  processBar(x as any);
}

• 아래 코드가 더 나은 이유는 any 타입이 다른 코드에 영향을 미치지 않기 때문이다.
• 타입스크립트가 함수의 반환타입을 추론할 수 있는 경우에도 함수의 반환타입을 명시하는 것이 좋다.
• 의도치 않은 타입 안전성의 손실을 피하기 위해 any의 사용 범위를 최소한으로 좁히자.
• 강제로 타입 오류를 제거하려면 any 대신 @ts-ignore를 사용하는 것이 좋다.

아이템 39. any를 구체적으로 변형해서 사용하기

• any는 매우 큰 범위의 타입이므로 일반적으론 더 구체적으로 표현 가능한 타입이 존재한다.

function getLengthBad(arr: any) {
  // ❌
  return arr.length;
}

function getLength(arr: any[]) {
  return arr.length;
  // 반환타입이 number로 추론
}

• 객체지만 속성에 접근할 수 없어야 한다면 unknown이 필요할 수 있다.
• 함수의 타입에도 단순히 any를 사용해서는 안 된다.

type Fn0 = () => any; // 매개변수 없이 호출 가능한 모든 함수
type Fn1 = (arg: any) => any; // 매개변수 1개
type Fn2 = (...args: any[]) => any; // 모든 개수의 매개변수 -> "Function"

아이템 40. 함수 안으로 타입 단언문 감추기

• 함수의 모든 부분을 안전한 타입으로 구현하는 것이 이상적이지만 불필요한 예외 상황까지 고려해 가며 타입 정보를 힘들게 구성할 피요는 없다.
• 함수 내부에는 타입 단언을 사용하고 함수 외부로 드러나는 타입 정의를 정확히 명시하는 정도로 끝내는 게 낫다.