前回のイベント処理からの続き
前回のI-06では、クリックや入力などの操作をイベントハンドラーで受け止め、stateの更新へつなぐ一本線を学びました。イベントハンドラーは、利用者の操作をきっかけに動く処理でした。今回扱うEffectは、それとは起点が違います。利用者の操作ではなく、画面が表示されたことなどをきっかけに、Reactの外側にある世界と足並みをそろえるための処理です。この違いを意識しながら進めましょう。
このスライドのポイント
- 前回I-06: 操作→イベントハンドラー→state更新→再描画の一本線
- イベントハンドラーの起点は「利用者の操作」
- 今回のEffectの起点は「画面が表示された」等、操作以外のきっかけ
- この講義の役割: Reactの外側（サーバー等）と足並みをそろえる処理を扱う
EffectとuseEffectの定義
Effectとは、レンダリング、つまりI-05で学んだ純粋な計算の外側で行う処理のことです。具体的には、サーバーからのデータ取得を始める、ブラウザのタブのタイトルを変えるといった、外部システムとの同期に使います。useEffectは、そのEffectを宣言するための道具で、いつ実行するかを依存する値で指定します。ここで最も大切な原則があります。描画の計算で済むことには、Effectを使わないということです。これはReactの公式でも示されている方針で、「Effectは最後の手段」と覚えてください。
このスライドのポイント
- Effect＝レンダリング（I-05の純粋な計算）の外側で行う処理
- 用途: サーバーからのデータ取得を始める、タブのタイトルを変える等、外部システムとの同期
- useEffect＝Effectを宣言する道具。「いつ実行するか」を依存する値で指定
- 原則: 描画の計算で済むことにEffectを使わない＝「Effectは最後の手段」（Reactの公式方針）
なぜ「最後の手段」と考えるのか
この原則を知らないと、AIが生成しがちなuseEffectだらけのコードの良し悪しを判断できません。Effectは便利に見えるため、AIは必要のない場面でも多用しがちです。その結果、同じ処理が繰り返し走る無限ループや、意図しない二重実行といった不具合の温床になります。なぜこの処理が2回実行されるのか、といった定番の混乱も、Effectの性質を知らなければ切り分けられません。
このスライドのポイント
- 知らないと: AIが生成しがちな「useEffectだらけのコード」の良し悪しを判断できない
- Effectは便利に見えるため、AIは不要な場面でも多用しがち
- 結果: 無限ループ・二重実行といった不具合の温床になる
- 「なぜ2回実行されるのか」等の定番の混乱も切り分けられない
「計算で導けるか」で判定する
Reactの処理は、大きく2つの領域に分けて考えると整理できます。1つは内側の領域、つまりレンダリングという純粋な計算です。もう1つは外側の領域、つまり外部との同期を担うEffectです。判断のコツは単純で、その値は計算で導けるかを最初に問うことです。stateやpropsから計算で導けるものは、Effectは不要です。計算では導けない、外の世界とのやり取りが必要なときだけ、Effectの出番になります。
このスライドのポイント
- Reactの処理を2領域で考える: 内側＝レンダリング（純粋な計算）／外側＝Effect（外部との同期）
- 最初の問い: その値はstate・propsからの計算で導けるか
- 計算で導ける → Effect不要
- 計算では導けず、外の世界とのやり取りが必要 → Effectの出番
具体例——データ取得はEffect、合計は計算
具体例で見ましょう。画面を開いたときに経費一覧をサーバーから読み込む処理は、典型的なEffectです。これは画面の外にあるサーバーとの同期であり、計算では導けないからです。一方で、経費の合計金額を画面に出す処理は、Effectを使ってはいけない例です。合計は手元の配列から計算できるので、Effectどころか、専用のstateを持つ必要すらありません。この2つの違いが、Effectを使うかどうかの分かれ目になります。
このスライドのポイント
- Effectを使う例: 画面を開いたら経費一覧をサーバーから読み込む＝外部との同期
- Effectを使わない例: 経費の合計金額の表示＝手元の配列から計算できる
- 合計は専用のstateを持つ必要すらない
- この2つの違いが「Effectを使うか」の分かれ目
技術サンプル——初回にデータを読み込む基本形
初回にデータを読み込むEffectの基本形を見てみましょう。読み方の要点は3つあります。1つ目は、2つ目に渡している空の配列がいつ実行するかの指定で、これは初回の表示後に1回だけ実行するという意味です。2つ目は、loadExpensesがサーバーへの依頼であり、F-05で学んだPromiseとして結果を受け取っている点です。3つ目は、取得した結果でstateを更新し、その結果として再描画が起きる点です。AIへの質問例としては、このuseEffectは何と同期していますか、描画時の計算で置き換えられませんか、と聞くとよいでしょう。
混同しやすい概念——計算で導ける値 vs 外部との同期
混同しやすいのは、描画の計算で導ける値と、外部との同期の区別です。合計、絞り込み、整形といった処理は、すべて手元のデータから計算で導けます。これらはEffect不要であり、多くの場合はstateにする必要すらありません。一方、サーバーからのデータ取得のように、Reactの外側とやり取りする処理だけが、本来のEffectの出番です。この線引きを持っていれば、不要なEffectを見分けられます。
バイブコーディングでの確認点
バイブコーディングでの確認点です。AIが書いたコードにuseEffectが出てきたら、1つずつ、これは何と同期していますか、と確認しましょう。もし答えがstateの計算をしているであれば、それはEffectの誤用です。その場合は、Effectを外して計算で書き直すようにAIへ指示します。この一手間が、無限ループや二重実行といった不具合を未然に防ぎます。
このスライドのポイント
- AIのコードにuseEffectが出たら、1つずつ「これは何と同期していますか」を確認
- 答えが「stateの計算をしている」ならEffectの誤用
- 誤用なら、Effectを外して計算で書き直すようAIへ指示
- この一手間が無限ループ・二重実行を未然に防ぐ
一問一答とまとめ
最後に一問一答です。問い。配列から合計を計算して表示するのに、Effectは必要でしょうか。（間）答えは、不要です。合計はレンダリング内の計算で済み、Effectはあくまで外部との同期のための道具だからです。30秒まとめとして、Effectは最後の手段であり、計算で導けることには使わない、と覚えておいてください。次回のI-08では、URLと画面の対応を決めるルーティングへ進みます。関連資料は「エラー解決プロンプト50」と「リファクタリング指示文50」です。
このスライドのポイント
- 一問一答: 配列から合計を計算して表示するのにEffectは必要か → 不要
- 30秒まとめ: Effectは最後の手段。計算で導けることには使わない
- 次回I-08: URLと画面の対応＝ルーティングへ
- 関連資料: 「エラー解決プロンプト50」「リファクタリング指示文50」
