3日目のゴールと今日やること
3日目のテーマは
「TypeScript の“現実のアプリでよく出る型”に触れて、型の便利さをさらに体で覚える」
ことです。
今日のゴールは次の 3 つ。
- オプショナル（あってもなくてもいい）なプロパティを理解する
- ユニオン型（A または B）を使って“選択肢のある型”を作れるようになる
- 状態（state）に型を付けて、小さなアプリを安全に動かす
1日目・2日目で「型って怖くない」感覚がついてきたので、
今日は “現実のアプリで必ず出てくる型” を扱っていきます。
オプショナルプロパティを理解する（? の意味）
「あるときもあれば、ないときもある」データは現実に多い
例えば、ユーザーのプロフィール。
type User = {
name: string;
age: number;
nickname?: string;
};
nickname の後ろに ? が付いています。
これは
「nickname はあってもなくてもいい」
という意味です。
実際のデータ例
const u1: User = {
name: "Alice",
age: 25,
nickname: "Ali"
};
const u2: User = {
name: "Bob",
age: 30
// nickname がなくても OK
};
深掘りポイント：? は「柔軟さ」を与える
現実のアプリでは、
「必ずあるとは限らない情報」が山ほどあります。
- 住所
- 電話番号
- プロフィール画像
- メモ
- オプション設定
TypeScript の ? は、
「このデータは必須じゃないよ」
と宣言するための仕組みです。
ユニオン型（A または B）で“選択肢のある型”を作る
まずはシンプルな例
let status: "loading" | "success" | "error";
これは
status は “loading” か “success” か “error” のどれか
という意味です。
実際のアプリでよくあるパターン
type LoadingState = "idle" | "loading" | "success" | "error";
こうしておくと、
間違った文字列を入れようとした瞬間に TypeScript が止めてくれます。
let state: LoadingState;
state = "loading"; // OK
state = "done"; // エラー（そんな状態は存在しない）
深掘りポイント：ユニオン型は「選択肢の型」
ユニオン型は、
「この変数は、この中のどれかになるよ」
という“選択肢の型”です。
アプリではよく使います。
- ローディング状態
- ボタンの種類
- エラーの種類
- フィルタの種類
- ソートの種類
JavaScript ではただの文字列ですが、
TypeScript では「選択肢のある型」として扱えます。
状態（state）に型を付けるとアプリが一気に安全になる
今日のミニアプリ：簡単な「カウンターアプリ」
HTML はこんな感じを想定します。
<button id="plus">＋</button>
<button id="minus">−</button>
<div id="display"></div>
状態（state）を型付きで管理する
type CounterState = {
count: number;
status: "idle" | "increased" | "decreased";
};
ここでのポイントは 2 つ。
count は number
status はユニオン型
初期状態
let state: CounterState = {
count: 0,
status: "idle"
};
状態を更新する関数
function updateState(newState: Partial<CounterState>) {
state = { ...state, ...newState };
}
ここで使っている Partial は
「全部のプロパティを指定しなくてもいいよ」
という便利な型です。
深掘りポイント：Partial は“部分的な更新”に最適
アプリの状態は、
「全部を一気に更新する」より
「一部だけ変える」ことの方が圧倒的に多いです。
Partial を使うと、
updateState({ count: state.count + 1 });
のように、
必要な部分だけ更新できます。
カウンターアプリのロジックを TypeScript で書く
HTML 要素の取得（型付き）
const plusButton = document.getElementById("plus") as HTMLButtonElement;
const minusButton = document.getElementById("minus") as HTMLButtonElement;
const display = document.getElementById("display") as HTMLDivElement;
表示を更新する関数
function render() {
display.textContent = `Count: ${state.count} / Status: ${state.status}`;
}
ボタンのイベント
plusButton.addEventListener("click", () => {
updateState({
count: state.count + 1,
status: "increased"
});
render();
});
minusButton.addEventListener("click", () => {
updateState({
count: state.count - 1,
status: "decreased"
});
render();
});
深掘りポイント：ユニオン型が“間違い”を防ぐ
もしこう書くと…
updateState({ status: "up" }); // エラー
TypeScript が止めてくれます。
“status は increased / decreased / idle のどれかだよ？”
これがユニオン型の強さです。
あえて間違えて「型のありがたさ」をもう一度体感する
わざと count を文字列にしてみる
updateState({ count: "10" }); // エラー
TypeScript はこう言います。
“count は number だよ？ 文字列は危ないよ？”
JavaScript なら普通に動いてしまい、
あとで「足し算したら変な結果になった…」というバグになります。
TypeScript は
「未来の自分を守るための安全装置」
だということが、ここでまた実感できます。
3日目のまとめ
今日あなたがやったことを整理するとこうです。
オプショナルプロパティ（?）で「柔軟な型」を作った。
ユニオン型（A | B | C）で「選択肢のある型」を作った。
Partial を使って「一部だけ更新できる型」を学んだ。
状態（state）に型を付けて、小さなカウンターアプリを作った。
わざと間違えて、TypeScript のエラーが「守ってくれている」感覚を再確認した。
今日いちばん深く理解してほしいこと
3日目の本質は、
「TypeScript の型は、現実のアプリの“あいまいさ”を安全に扱うための道具」
ということです。
- あってもなくてもいい情報（?）
- いくつかの選択肢しかない状態（ユニオン型）
- 一部だけ更新したい状態（Partial）
これらは、
実際のアプリで必ず出てくる“現実のデータの形”です。
4日目では、
配列操作 × TypeScript の型
を組み合わせて、
「検索・フィルタ・ソート」などの処理を
型安全に書けるようにしていきます。
