2日目のゴールと今日やること
2日目のテーマは
「オブジェクトと配列にも“型の安心感”を広げる」
ことです。
1日目は、number / string / boolean と、
関数に型を付ける感覚をつかみました。
2日目のゴールはこうです。
オブジェクトに「型の形」を付けられるようになる。
配列に「中身の型」を付けられるようになる。
型エイリアス（type）で「名前の付いた型」を作れるようになる。
「難しい理論」ではなく、
“アプリでよく出てくる形に型を付けてみる” ことに集中します。
オブジェクトに「型の形」を付けてみる
まずは型なしのオブジェクト
JavaScript だけだと、こんな感じで書きます。
const user = {
name: "Alice",
age: 25
};
ここで問題なのは、
「name が string で、age が number だ」という情報が
コードを読まないとわからない ことです。
TypeScript では、ここに「型の形」を付けます。
オブジェクトの型をその場で書く
const user: {
name: string;
age: number;
} = {
name: "Alice",
age: 25
};
これで TypeScript はこう理解します。
name は string。
age は number。
そして、もしこう書くとエラーになります。
const user: {
name: string;
age: number;
} = {
name: "Alice",
age: "25" // エラー
};
深掘りポイント：オブジェクトの型は「設計図」
オブジェクトの型は、
「このオブジェクトは、こういうプロパティを持っていて、
それぞれこういう型です」という設計図 です。
設計図と違うものを作ろうとすると、
その場で止めてくれます。
型エイリアスで「名前の付いた型」を作る
いちいち同じ形を書くのはつらい
さっきの user の型を、
別の場所でも使いたくなったとします。
毎回こう書くのはしんどいです。
const user: {
name: string;
age: number;
} = { ... };
function printUser(u: { name: string; age: number }) {
// ...
}
ここで登場するのが 型エイリアス（type） です。
type で「型に名前を付ける」
type User = {
name: string;
age: number;
};
これで、User という「型の名前」ができました。
あとはこう書けます。
const user: User = {
name: "Alice",
age: 25
};
function printUser(u: User) {
console.log(`${u.name} (${u.age}歳)`);
}
深掘りポイント：type は「型のニックネーム」
type User = … は、
「この形のことを、これから User と呼びます」
という宣言です。
長い型を毎回書かなくてよくなる。
「この関数は User を受け取る」と一目でわかる。
あとから User の形を変えたくなっても、
type User の定義だけ直せばよい。
これは、アプリが大きくなったときに
効いてくる「未来への投資」です。
配列に「中身の型」を付けてみる
型なしの配列
const scores = [80, 90, 70];
JavaScript だけだと、
「この配列は number の配列だよ」という情報は
人間が見て判断するしかありません。
TypeScript では、こう書きます。
number の配列
const scores: number[] = [80, 90, 70];
これで TypeScript は
「scores は number だけが入る配列」
だと理解します。
もしこう書くとエラーです。
scores.push("100"); // エラー
オブジェクトの配列
さっきの User 型を使って、
ユーザー一覧を作ってみます。
type User = {
name: string;
age: number;
};
const users: User[] = [
{ name: "Alice", age: 25 },
{ name: "Bob", age: 30 }
];
ここで TypeScript はこう理解します。
users は「User 型の配列」。
つまり、配列の中身は全部 User。
もし、プロパティが足りなかったり、型が違うとエラーです。
const users: User[] = [
{ name: "Alice", age: 25 },
{ name: "Bob" } // age がないのでエラー
];
深掘りポイント：配列の型は「中身のルール」
number[] は「中身が全部 number」。
User[] は「中身が全部 User 型」。
「この配列には、こういうものだけが入ります」というルール を
TypeScript に教えているだけです。
2日目のミニアプリ：簡単な「ユーザー一覧」を作る
こんなデータを扱うと決める
type User = {
name: string;
age: number;
};
配列でユーザー一覧を持つ
const users: User[] = [
{ name: "Alice", age: 25 },
{ name: "Bob", age: 30 },
{ name: "Charlie", age: 22 }
];
一覧を表示する関数を書く
function formatUser(user: User): string {
return `${user.name}（${user.age}歳）`;
}
function printUsers(list: User[]): void {
list.forEach((user) => {
console.log(formatUser(user));
});
}
ここでのポイントはこうです。
formatUser は User を受け取って string を返す。
printUsers は User[] を受け取って、何も返さない（void）。
TypeScript は、
「この関数は何を受け取って、何を返すのか」
を常に意識させてくれます。
あえて間違えて「型のありがたさ」をもう一度体感する
わざと age を文字列にしてみる
const users: User[] = [
{ name: "Alice", age: 25 },
{ name: "Bob", age: "30" } // エラー
];
TypeScript はこう言ってきます（ざっくり）：
“User の age は number って言ってたのに、
ここで string 入れてるよ？ 危ないよ？”
これがもし JavaScript だけなら、
エラーにならずにそのまま動いてしまいます。
そして、どこか別の場所で
「年齢を足し算しようとしたらおかしくなった」
というバグになります。
TypeScript は、
「バグが生まれる前に止めてくれる」
という意味で、本当に優秀なガードマンです。
2日目のまとめ
今日あなたがやったことを、感覚ベースで整理するとこうです。
オブジェクトに「形の型」を付けた。
type で「型に名前」を付けた。
配列に「中身の型」を付けた（number[] / User[]）。
User 型を使って、ユーザー一覧のミニアプリを書いた。
わざと間違えて、TypeScript のエラーが「守ってくれている」感覚をもう一度味わった。
今日いちばん深く理解してほしいこと
2日目の本質は、
「型は“データの形”をはっきりさせることで、未来の自分を守ってくれる」
ということです。
オブジェクトの型は「設計図」。
配列の型は「中身のルール」。
type は「その設計図に名前を付ける仕組み」。
まだ全部を完璧に覚える必要はありません。
User みたいな「自分で決めた形」に
名前を付けて使い回せたなら、
2日目としては十分すぎるくらいです。
3日目では、
オプショナルなプロパティ（あってもなくてもいい値）。
ユニオン型（「A か B」のような型）。
簡単な状態管理に型を付ける。
といった、
「現実のアプリに近づくための型」
を一緒に触っていきます。
