propsだけでは足りないデータがある
前回のI-03では、親から子へ一方向で値を渡すpropsを学びました。propsは子が書き換えない、読み取り専用の値でしたね。しかし画面には、propsだけでは足りない、部品自身が持って変化させるデータがあります。たとえば入力中の文字や、送信中かどうかといった状態です。この講義では、その変化するデータをReactでどう扱うのか、stateという仕組みを見ていきます。
このスライドのポイント
- I-03の復習: propsは親から子への一方向、子は書き換えない読み取り専用
- しかし部品には「自分で持って変化させる」データがある
- 例: 入力中の文字、送信中かどうか
- この講義: その変化するデータをReactで扱う仕組み＝state
stateとuseStateの定義
stateとは、コンポーネント自身が持つ、変化するデータのことです。H-06で設計した画面の状態を、Reactで実装したものにあたります。このstateを宣言する道具がuseStateです。useStateを使うと、現在の値と、更新するための関数の2つがペアで返ってきます。大切な決まりは、値の更新は必ずこの更新関数を通して行うことです。現在の値を直接書き換えるのは、F-03で学んだミューテーション、つまり元のデータを直接いじる行為にあたり、画面が更新されない典型的なバグになります。
このスライドのポイント
- state＝コンポーネント自身が持つ、変化するデータ（H-06で設計した「状態」の実装）
- useState＝stateを宣言するReactの道具
- useStateは「現在値」と「更新用の関数」のペアを返す
- 更新は必ず更新関数で行う
- 直接書き換えはF-03のミューテーションにあたり、画面が更新されない典型バグ
なぜ必要か——「変えたのに画面が変わらない」の正体
stateを理解していないと、Reactで最初に必ずぶつかる壁が越えられません。それは、変数の値を変えたのに画面が変わらない、という現象です。ふつうの変数は、値を変えてもReactはそれに気づかず、画面を計算し直しません。stateとして持ち、更新関数で変えたときだけ、Reactは変化を検知して再描画します。この区別がないと、なぜ画面が動かないのかを説明できず、AIへ的確な修正も頼めません。
このスライドのポイント
- Reactで最初にぶつかる壁: 変数を変えたのに画面が変わらない
- ふつうの変数は、値を変えてもReactが気づかず再計算しない
- stateとして持ち、更新関数で変えたときだけ再描画される
- この区別がないと、AIへ的確な修正も頼めない
構造——stateが画面へ反映される循環
stateが画面に反映されるまでの流れは、1つの循環になっています。まず利用者が操作します。次にその操作が更新関数を呼び、stateの値が変わります。stateが変わると、Reactが画面を計算し直す再描画が起こり、新しい表示になります。この循環の入口が操作で、出口が新しい画面です。ここで注意したいのは、現在の値を直接書き換えても、この循環には乗らないことです。だから画面は変わりません。
このスライドのポイント
- 循環: 操作 → 更新関数を呼ぶ → stateが変わる → 再描画（次回I-05）→ 新しい表示
- 入口は操作、出口は新しい画面
- 現在値を直接書き換えると、この循環に乗らない＝画面は変わらない
具体例——送信中の状態をstateで実装する
具体例として、H-06で設計した送信中の状態を実装してみましょう。isSubmittingという名前のstateを1つ持ちます。送信を開始したら更新関数でtrueにし、完了したらfalseに戻します。そしてtrueの間は、ボタンを押せないようにします。H章で図として描いた状態の設計が、このstateとしてそのままコードになる瞬間です。設計と実装が地続きであることが、ここで実感できます。
このスライドのポイント
- H-06で設計した「送信中」の状態をstateにする
- isSubmittingというstateを1つ持つ
- 送信開始で更新関数によりtrue、完了でfalse
- trueの間はボタンを押せなくする
- 設計（H章）が実装（I章）になる瞬間
技術サンプルカード
サンプルは、申請件数を数える小さなボタンです。useStateにゼロを渡し、初期値ゼロのstateを用意しています。返ってくるcountが現在の値、setCountが更新関数です。ボタンをクリックするとsetCountが呼ばれ、値が1増えて再描画されます。読み方の要点は3つです。返り値は現在の値と更新関数のペアであること、setCountを呼ぶと再描画されること、そしてcountに直接1を足して代入しても画面は変わらないことです。
混同しやすい——propsとstate
混同しやすいのが、propsとstateの違いです。propsは親から与えられる読み取り専用の値で、I-03で学びました。一方stateは、その部品自身が持ち、自分で変化させるデータです。どちらにデータを置くか迷ったら、2つを自問してください。そのデータは変化するか、そして誰が持つべきか。変化せず親が決めるならprops、変化して自分が持つならstateです。
バイブコーディングでの確認点
画面が更新されないという不具合に出会ったら、確認の順番を決めておきましょう。まずstateを直接書き換えていないかを疑います。次に、更新関数をきちんと使っているかを確かめます。AIが書いたコードでも、この2点をAIに確認させると原因が絞れます。stateなのか、ふつうの変数なのか、その区別が曖昧なコードは、この不具合の温床になります。
このスライドのポイント
- 「画面が更新されない」不具合の確認順を固定する
- ① stateを直接書き換えていないか
- ② 更新関数をきちんと使っているか
- state なのか、ふつうの変数なのか、区別が曖昧なコードは要注意
- AIに上の2点を確認させると原因が絞れる
まとめと一問一答
最後に一問一答です。stateを変えるとき、必ず使うものは何でしょうか。……答えは、更新関数です。useStateが返す2つ目の値で、これを使わず直接代入しても再描画されません。30秒まとめです。stateは部品自身が持つ変化するデータ、更新は必ず更新関数を通す、直接書き換えると画面が変わらない。この3点を押さえてください。次回のI-05では、その再描画そのものの仕組み、レンダリングを扱います。関連資料は「AIチャットUI設計パターン」「エラー解決プロンプト50」です。
このスライドのポイント
- 一問一答:「stateを変えるのに必ず使うものは？」→ 更新関数（useStateが返す2つ目。直接代入では再描画されない）
- 30秒まとめ: stateは部品自身が持つ変化するデータ／更新は必ず更新関数を通す／直接書き換えると画面が変わらない
- 次回: I-05 レンダリング（再描画の仕組み）
- 関連資料: 「AIチャットUI設計パターン」「エラー解決プロンプト50」
