はじめに

前回は、Angular・Node.js・TypeScriptそれぞれの役割を整理した。

今回はその中でも、
この学習全体の土台になる TypeScript について、
「文法」ではなく 考え方 を中心に整理してみる。

TypeScriptは、
JavaScriptを便利にするための道具というより、
設計をコードに落とすための道具 として見る方がしっくりくる。

---

なぜ TypeScript が必要なのか

JavaScriptだけでも、アプリは作れる。

それでもTypeScriptを使う理由は明確で、

• 実行する前にミスが分かる
• 変数やデータの意味がはっきりする
• 規模が大きくなっても破綻しにくい

という点にある。

特に業務アプリでは、
「あとから見返す」「他人が読む」前提になるため、
型があること自体がドキュメントになる。

---

型は「制約」ではなく「説明」

TypeScriptの型は、
「縛るもの」「面倒なもの」と思われがちだが、実際は逆。

型は、

このデータは、どういう意味を持つのか

を説明するためのもの。

たとえば次のようなコード。

let userId: number;

これは単に数値というだけでなく、
**「ユーザーIDとして使う数値」**だと分かる。

---

interface は設計書そのもの

TypeScriptで特に重要なのが interface。

interface User {
  id: number;
  name: string;
  email?: string;
}

これだけで、

• Userとは何か
• どんな項目を持つのか
• 省略可能な項目は何か

が一目で分かる。

これはもう、
コードに書かれた設計書と言っていい。

---

フロントとバックで「同じ型」を見る意味

Angular（フロント）とNode.js（バック）は、
本来まったく別の世界。

それでもTypeScriptを使うことで、

• フロント側で扱うデータ
• APIで返ってくるデータ
• バック側で処理するデータ

を 同じ構造として考えられる。

これは、

• データのズレ
• 解釈違い
• 「思ってた形と違う」

といったトラブルを大きく減らす。

---

class は「データ＋振る舞い」

TypeScriptの class は、

• データ
• そのデータに対する処理

をひとまとめにできる。

class UserService {
  getUserName(user: User): string {
    return user.name;
  }
}

ここでは、

• User というデータ構造
• それをどう扱うか

がセットになっている。

AngularやNode.jsでは、
この考え方がそのまま Service に繋がっていく。

---

型があると「考える時間」が減る

実際に書いてみると分かるが、
型があると、

• この変数、何入ってたっけ？
• null来る可能性ある？
• 配列？オブジェクト？

といったことを
コードを読むだけで判断できる。

これは地味だが、
開発スピードと安心感に直結する。

---

Day02 時点でのスタンス

この段階では、

• 難しい型
• ジェネリクスの深掘り
• 高度な型演算

は不要。

まずは、

• interface が書ける
• 関数の引数と戻り値に型を付ける
• class の意味が分かる

これだけで十分。

---

Day02 のまとめ

• TypeScriptは「JavaScriptの拡張」ではない
• 型は制約ではなく説明
• interfaceは設計書
• classは設計＋処理
• Angular / Node.js 両方の土台になる

次回は、
Node.jsで最初のAPIを作りながら、
TypeScriptをどう使うかを見ていく。

---

次回予告

Day03：Node.jsで最初のAPIを作る（TypeScript編）