Why Types：TypeScript 到底替你做了什麼？

Why now：JavaScript 已經能跑，為什麼還需要 TypeScript？

function total(price, quantity) {
  return price * quantity;
}

total("100", 2);

JavaScript 可以執行這段，而且結果可能剛好是 200。但這種「靠 coercion 剛好能跑」會讓大型專案的 contract 很模糊。

Learning outcomes

• 能說明 TypeScript type checking 與 JavaScript runtime 的邊界。
• 能分辨 inference、annotation、any、unknown。
• 能解釋為什麼 interface 不會自動驗證 API response。
• 能指出 type error 與 runtime error 會在哪一層出現。

1. Annotation 與 inference

let score: number = 90;

const age = 20;
// TypeScript 通常可推斷 age 是 number

不是每個變數都需要手寫型別。好的 TypeScript 會善用 inference，把型別寫在「contract boundary」而不是到處重複資訊。

2. Type checker 可以攔什麼？

function total(price: number, quantity: number): number {
  return price * quantity;
}

total("100", 2);
// type error

這個錯在 build / editor 階段就可看到，甚至 Browser 還沒拿到 JavaScript。

3. TypeScript 不能攔什麼？

type Course = {
  id: number;
  title: string;
};

const response = await fetch("/api/course/1");
const raw = await response.json();

// raw 是 runtime data
// Server 完全可能回：
// { "id": "oops", "title": null }

你在 source 裡宣告 Course，不會改變網路上的 JSON。Type system 只知道你告訴它的資訊，不會神奇地檢查 remote server。

4. any vs unknown：外部資料的安全邊界

let unsafe: any = await response.json();
unsafe.not.real.deep.value(); // 幾乎不阻止你

let raw: unknown = await response.json();
// raw.title // 不允許，先證明它的形狀

5. Project checkpoint：Typed Course API Client v1

type Course = {
  id: number;
  title: string;
  score: number | null;
};

async function loadCourse(id: number): Promise<unknown> {
  const response = await fetch("/api/courses/" + id);

  if (!response.ok) {
    throw new Error("HTTP " + response.status);
  }

  return response.json();
}

這個版本故意回 Promise<unknown>。下一課才把 domain model 與 loading/error state 建完整。

6. Debug evidence：同一句「TypeScript 報錯」可能完全不同