【第17回】手で画面を書き換える限界を知る｜フレームワークが要る理由（嫁子が教えるTS講座）
今回のゴール
- ReactやNext.jsが何を肩代わりしてくれるのかを説明できる
- 「宣言的に書く」という言い方の意味が分かる
- 今日はコードを書きません。次回から動かします
ここから第4部（フロントエンド）です。前回（TypeScriptへの書き換え）で第3部は終わりました。全体の流れは講座の目次へ。
嫁子: 第4部からは、たぶんあなたが「Webアプリを作る」と聞いて想像してたものに近づくよ。
ただ今日は道具の紹介じゃなくて、なんでその道具が生まれたのかの話をするね。ここを飛ばすと、Next.jsが「よく分からないけど皆が使ってるもの」のままになっちゃうから。
① 第2部で作ったアプリの、どこが限界だったか
第10回の買い物メモを思い出してください。品物を追加するたびに、こう書いていました。
items.push({ name: name, done: false });
render();
データを変えたあと、自分で render() を呼んでいます。呼び忘れたら、データは増えているのに画面は古いままです。エラーも出ません。
品物3つのアプリなら覚えていられます。ところが画面に「残り件数」「合計金額」「未購入だけのリスト」「並び替え」が加わると、データを変える場所も画面を直す場所も増えていきます。
| アプリの規模 | データを変える場所 | 忘れずに更新すべき箇所 |
|---|---|---|
| 買い物メモ（第10回） | 3か所 | 1か所（render） |
| 現実のアプリ | 数十か所 | 十数か所 |
「呼び忘れ」が起きる確率は、掛け算で増えていきます。
② 命令的に書くか、宣言的に書くか
第2部のやり方は、手順を一つずつ命令する書き方でした。
// 命令的：どうやって画面を変えるかを、全部書く
list.textContent = "";
items.forEach((item) => {
const li = document.createElement("li");
li.textContent = item.name;
list.appendChild(li);
});
Reactでは、こう書きます。
// 宣言的：どういう画面であるべきかだけ書く
<ul>
{items.map((item) => <li key={item.name}>{item.name}</li>)}
</ul>
違いは手順を書いているか、結果を書いているかです。上は「空にして、作って、くっつけて」と手順を並べています。下は「items の中身がそのまま li として並んだ状態」と、あるべき姿だけを書いています。
そして items が変わると、画面は自動で追いつきます。render() に相当する呼び出しは要りません。
嫁子: 料理で言うとね。命令的は「レシピの手順書」、宣言的は「完成写真」なの。
手順書だと、途中で材料が変わったとき全部書き直しでしょ。完成写真を渡す方式なら、材料が変わっても写真の指定はそのままでいい。差分を考えるのは道具の仕事、っていう分担だね。
③ Reactが実際にやっていること
「自動で追いつく」と言っても、魔法ではありません。裏では第9回でやったDOM操作が動いています。
Reactは、データが変わるたびに「本来こうあるべき画面」を計算し直し、いま表示されている画面と見比べて、違う部分だけを書き換えます。
だから第9回であなたが手でやっていた作業は消えたわけではなく、書く人が人間から機械に変わっただけです。
ここが「第9回をやった意味」です。中で何が起きているか想像できると、うまく動かないときに「これはデータ側の問題か、表示側の問題か」を切り分けられます。
④ ReactとNext.jsの関係
名前が2つ出てきて混乱しやすいので、整理します。
| 役割 | たとえるなら | |
|---|---|---|
| React | 画面を部品に分けて、データと同期させる仕組み | エンジン |
| Next.js | Reactを使ってサイトを作るための、周辺一式 | 車 |
Reactだけでは、ページの切り替え（ルーティング）や、サーバー側の処理、公開用のファイル生成といったものが付いてきません。それらを最初から用意してあるのがNext.jsです。
この講座がNext.jsを選ぶ理由は3つあります。
- AIに「Webアプリを作って」と頼むと、多くの場合これを前提に提案してくる
- フロントエンドとサーバー側（第5部）を同じ枠組みで書ける
- 公開までの手順が短い（第28回でやります）
嫁子: 「ReactとNext.jsどっちを学べばいいの？」ってよく聞かれるけど、並んでいる選択肢じゃないんだよね。
Next.jsを使う＝Reactも使ってる、なの。だから今日から出てくるコードは、両方が混ざってる状態だと思っておいて。
⑤ 何が楽になり、何が増えるのか
正直に両面を書いておきます。
楽になること
- 画面の更新漏れが構造的に起きなくなる
- 部品ごとに切り分けられるので、AIに「この部品を直して」と頼める
- ページの追加やURL設計が、ファイルを置くだけで済む
増えること
- 覚える言葉が増える（コンポーネント、Props、State、フック）
- ファイルが一気に増える。最初は「どこに何があるか」で迷う
- 環境の準備が必要になる（次回やります）
小さなツール1つなら、第9回のやり方のほうが速いこともあります。判断の目安は「画面に出る情報が、データの変化で何か所も変わるかどうか」です。
嫁子: 全部これで作れ、とは言わないよ。ページ1枚の計算ツールなら、素のJavaScriptで十分なこともあるからね。
ただ、AIに任せるなら話が変わるの。AIが得意なのは、みんなが使っている型に乗ったコードだから。Next.jsの標準的な構成で頼んだほうが、返ってくるものの質は上がるよ。
つまずきポイント
「フレームワーク」という言葉に身構えなくて大丈夫です。やっていることは、面倒な繰り返しを肩代わりする仕組みの集まりです。
第2部・第3部の知識はそのまま使います。配列も関数も型も、そのまま出てきます。新しく覚えるのは書き方の枠組みだけです。
今回のまとめ
- 手で
render()を呼ぶ方式は、規模が大きくなると呼び忘れが必ず起きる - Reactは「あるべき画面」を書くと、データの変化に画面が自動で追いつく
- 裏でやっているのは第9回のDOM操作。書く人が人間から機械に変わっただけ
- Next.jsはReactを含んだ一式。AIが提案してくる標準的な土台でもある
- 小規模なら素のJavaScriptで十分なこともある
次にやること
次回はNext.js を動かすです。実際にプロジェクトを作って、ブラウザで表示するところまでやります。
今回の宿題：AIに「なぜReactが必要なのか、DOM操作と比べて説明して」と聞いてみてください。今日読んだ内容と照らして、説明が腑に落ちるかどうかを確かめるのが目的です。
嫁子: 同じ質問を人にもAIにもぶつけて、答えを見比べるのって良い勉強法だと思う。
今日の回を読んだあとなら、返ってきた説明の良し悪しが分かるはずだよ。それができたら、もう「ただ読む人」ではないからね。