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

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

---

아이템 34: 부정확한 타입보다는 미완성을 사용하기 Prefer Imprecise Types to Inaccurate Types

• 타입이 구체적일 수록, 버그를 많이 잡고 도구를 활용할 수 있다.
• 타입 선언의 정밀도를 높여야 합니다. 잘못된 타입은 없는 것보다 못하다.

interface Point {
  type: "Point";
  coordinates: number[];
}
interface LineString {
  type: "LineString";
  coordinates: number[][];
}
interface Polygon {
  type: "Polygon";
  coordinates: number[][][];
}
type Geometry = Point | LineString | Polygon;
...
// ❗️ 타입 선언을 더 세밀하게 만들기 위한 시도
// 하지만 Point에 위도 경도를 제외한 고도가 있거나, 다른 정보가 있다면, 타입이 부정확해져 빌드를 깨트릴 수 있다.
// 사용자가 타입 단언을 하거나, as any로 타입 체커를 무시해야 하는 상황이 생김
type GeoPosition = [number, number];
interface Point {
  type: 'Point';
  coordinates: GeoPosition;
}

예시: Mapbox 라이브러리

• 정밀도 유지하면서 오류 잡기

// ❗️ Mapbox 라이브러리는 아래와 같은 시스템으로 지도 기능의 형태를 결정
["+", 1, 2];
[("/", 20, 2)];
[("case", [">", 20, 10], "red", "blue")];
[("rgb", 255, 0, 127)]; // 3 // 10 // "red" // #FF007F

// 👾 테스트 케이스!
const okExpressions = [
  10,
  "red",
  ["+", 10, 5],
  ["rgb", 255, 128, 64],
  ["case", [">", 20, 10], "red", "blue"],
];
const invalidExpressions = [
  true, // (boolean 안됨) ~~~ Type 'boolean' is not assignable to type 'Expression2'
  ["**", 2, 31], // (없는 FnName) Should be an error: no "**" function
  ["rgb", 255, 0, 127, 0], // (RGB 색상값이 3개여야함) Should be an error: too many values
  ["case", [">", 20, 10], "red", "blue", "green"], // (분기값이 2개여야 함) Too many values
];

// 동작을 모델링할 수 있는 입력값

// 📌 전부 통과 👎
type Expression1 = any;

// 📌 에러 케이스 중 boolean만 거를 수 있음
type Expression2 = number | string | any[];
const invalidExpressions: Expression2[] = [
  true, // ✅
  ["**", 2, 31],
  ["rgb", 255, 0, 127, 0],
  ["case", [">", 20, 10], "red", "blue", "green"],
];

// 📌 정밀도 높이기~!
type FnName = "+" | "-" | "*" | "/" | ">" | "<" | "case" | "rgb"; // 문자열 리터럴의 유니온 사용
type CallExpression = [FnName, ...any[]];
// 첫번째 expression은 FnName이고, 나머지는 Any일 것
type Expression3 = number | string | CallExpression;

const okExpressions: Expression3[] = [
  10, // number!
  "red", // string!
  ["+", 10, 5], // CallExpression!
  ["rgb", 255, 128, 64], // CallExpression!
  ["case", [">", 20, 10], "red", "blue"], // CallExpression!
];
const invalidExpressions: Expression3[] = [
  true, // ✅
  ["**", 2, 31], // ✅
  ["rgb", 255, 0, 127, 0],
  ["case", [">", 20, 10], "red", "blue", "green"],
];

// 📌 매개 변수 갯수 체크하기
// - 재귀로 모든 함수 호출을 확인한다? nope
// - 인터페이스 추가하기 (여러 인터페이스를 호출 표현식으로 묶을 수 없음)
// => type Expression4 = number | string | (MathCall | CaseCall | RGBCall) 이런 느낌으로 안된다는 뜻
type Expression4 = number | string | CallExpression;
type CallExpression = MathCall | CaseCall | RGBCall; // 함수종류 유니온

// MathCall 타입의 첫 번째 index는 두 값을 연산하는 FnName이다.
type MathCall = ["+" | "-" | "/" | "*" | ">" | "<", Expression4, Expression4];

// CaseCall은 Array like한 타입이다.
// 첫 번째 index는 "case" 문자열이고, 특정 길이의 유니온을 length로 가진다.
interface CaseCall {
  0: "case";
  [n: number]: Expression4;
  length: 4 | 6 | 8 | 10 | 12 | 14 | 16; // etc.
}

// RGBCall 타입의 첫 번째 index는 "rgb"이다.
// 튜플 형태이며, 3개의 Expression4의 타입을 가진다.
type RGBCall = ["rgb", Expression4, Expression4, Expression4];

const invalidExpressions: Expression4[] = [
  true, // ✅
  // ~~~ Type 'boolean' is not assignable to type 'Expression4'
  ["**", 2, 31], // ✅
  // ~~~~ Type '"**"' is not assignable to type '"+" | "-" | "/" | ...
  ["rgb", 255, 0, 127, 0], // ✅
  //                   ~ Type 'number' is not assignable to type 'undefined'.
  ["case", [">", 20, 10], "red", "blue", "green"], // ✅
  // Types of property 'length' are incompatible.
  //    Type '5' is not assignable to type '4 | 6 | 8 | 10 | 12 | 14 | 16'.
];
// 타입 정보가 정밀해졌음
// 덕분에 잘못된 코드에서 전부 오류가 발생하지만, 타입 에러 시 메시지가 부정확하다.
// 더 구체적이지만, 자동 완성을 방해하므로 개발 경험을 해치게 된다.

타입 선언이 복잡해지면?

• 버그가 발생할 가능성이 높아진다.
  • 부정확함을 타입으로 바로잡지 않고, 테스트 세트를 추가하자.
  • 정밀한 타입은 코드의 버그로 이어질 수 있다(화날 수 있음)
• 타입을 정제 refine할 때, 불쾌한 골짜기 은유를 생각하자?
  • 물론 any같은 타입은 정제하기
  • 타입을 구체적으로 정제한다고 해서? 정확도가 비례해서 올라가지 않다.
• 타입에 의존하면 부정확함으로 발생하는 문제가 눈덩이

const moreOkExpressions: Expression4[] = [
  ["-", 12], // 👾 입력을 음수로 바꿔주는 기능 사용 시 잘못된 오류
  // ~~~~~~ Type '["-", number]' is not assignable to type 'MathCall'.
  //          Source has 2 element(s) but target requires 3.
  ["+", 1, 2, 3], // 👾 2개 이상의 수를 연산할 때 잘못된 오류
  //          ~ Type 'number' is not assignable to type 'undefined'.
  ["*", 2, 3, 4],
  //          ~ Type 'number' is not assignable to type 'undefined'.
];

Things to Remember

• Avoid the uncanny valley of type safety: complex but inaccurate types are often worse than simpler, less precise types. If you cannot model a type accurately, do not model it inaccurately! Acknowledge the gaps using any or unknown.
  • 타입이 단순하고 불분명한 것보다, 복잡하면서 정확하지 않은 것이 훨씬 더 나쁘다.
  • 정확하게 모델링할 수 없다면? 부정확하게 하지나 말자. (any나 unknown과는 또 다른 이야기임)
• Pay attention to error messages and autocomplete as you make typings increasingly precise. It's not just about correctness: developer experience matters, too.
  • 타입 정보를 구체적으로 작성하려 할 수록 >>> 자동 완성과 오류 메시지를 주의깊게 보자. 정확도 & DX 향상!
• As your types grow more complex, your test suite for them should expand.
  • 타입이 복잡해지는 만큼 테스트 케이스도 많아져야 한다.