なぜ必要なのか
家族が買い物と献立を保存する計画アプリを作るとします。各カードと合計を揃えて更新する必要があります。制作側は変化する状態からJavaScript関数でUIを表したいと考えます。
どう解決するのか
家庭の計画アプリのカード2枚は未保存で開始します。買い物リストを保存すると、そのカードだけ保存済みになり、週間メニューは変わりません。週間メニューも保存すると合計は1から2になります。同じカードを再び保存しても合計は2です。図はイベント・状態更新・描画をつなぎます。リセット・再読み込みで両方を消します。永続保存はありません。
各カードを保存します。カードごとに1回だけ数え、もう一方は変わりません。
共通の保存状態
タイトルのプロップス ↓ · 親の状態から各カードに保存状況を渡す
買い物リスト
これからの一週間に
週間メニュー
夕食を決めておく
- 保存イベント
- 状態設定が描画を要求
- ラベルと合計を描画
保存数: 0 / 2
買い物リスト: 0 · 週間メニュー: 0
待機
本文内の架空のデモです。リセット・再読み込みで初期状態に戻ります。
どんな考え方なのか
Reactのコンポーネントはプロップスを受け取り、状態からUIを表します。状態の設定関数は描画を要求します。通常の変数を変えるだけでは同じ仕組みになりません。
永続保存は別に追加します。
出典
さらに詳しく
任意の参考資料 · 概要の読了時間には含みません
01選択・比較
JavaScriptのコンポーネントでUIを再利用し、状態の所有者を明確にしたいチームに向きます。テンプレート中心のVueやコンパイラー中心のSvelteが、好みや既存コードに合う場合もあります。ほぼ静的なページなら小さな操作領域だけで足りるかもしれません。フレームワークを選んでも保存・認証・配置は決まりません。
02応用例
家庭の計画には買い物と献立のカードがあります。一方を保存すると他方を保ちつつ、そのラベルと合計を更新します。実際のReactでは最も近い共通の親に選択IDを置き、値とハンドラーを渡せます。作例は状態の流れを説明するブラウザー上の模型で、Reactバンドルは実行しません。再読み込みで意図的に消します。
03実装の参考・注意点
状態の設定関数で描画を要求します。前の値から次を求めるなら setSaved(previous => previous.includes(id) ? previous : [...previous, id]) のような更新関数を使います。合計を別々に保存してずれを生まず、同じ配列から求めます。描画に副作用を入れません。複数端末の保存には、待機・失敗・再試行を含む別の永続化契約が必要です。
04根拠
比較のまとめ
続けて読む
原稿・修正提案 ↗自分のプロジェクトに活かす
これからプロジェクトを始めますか？説明を入力して最初のプロンプトを準備しましょう。
自分に合うプロンプトを作る →すでに外部AIと会話中なら、この記事のリンクと自分のプロジェクトに合う理由、重視する利点や制約を伝えましょう。合意した要件にどう適用するか依頼してください。
この記事のリンク: React
この選択を話し合う
コメントは全言語で共有。投稿にはGitHubログインが必要です。