状態管理 — データは一方通行でしか流れない
画面のあちこちから状態（state）を直接書き換えていると、「いつ・どこで・誰が変えたのか」が分からなくなり、バグの温床になります。Redux に代表される状態管理は、この混乱を「データは一方向にしか流れない」という1本のルールで断ち切ります。
View（画面）は state を直接いじれません。代わりに「何が起きたか」を表す Action を発行（dispatch）するだけ。それを受けて Reducer が新しい state を計算し、Store が保存して、画面が描き直されます。下の図1のボタンを押して、この一方通行のサイクルが回る様子を見てください。
一方通行だから、追いかけられる
このサイクルの主役は Reducer です。Reducer は (現在のstate, action) → 新しいstate という純粋関数。同じ入力なら必ず同じ出力を返し、外の世界に副作用を起こしません。だから「この Action が来たら、state はこう変わる」が完全に予測でき、テストも簡単です。図1で +1 を押すと、Reducer が count + 1 を計算して新しい state を作る様子が見えます。
そして state を書き換える唯一の入口が Action の発行だけに絞られているのが効きます。変更は必ず1か所（Reducer）を通るので、「いつ・どんな Action で・どう変わったか」が一本の履歴として残ります。これが「タイムトラベルデバッグ（操作を巻き戻して再生する）」を可能にする理由です。View がてんでに state をいじる双方向の世界では、こうはいきません。
- Store
- アプリ全体の state（状態）を1か所に保管する場所。真実は常にここにある。
- Action
- 「何が起きたか」を表すただのデータ（例:
{type:'increment'}）。発行することを dispatch という。 - Reducer
- (現在のstate, action) から新しい state を作る純粋関数。状態変更はここだけを通る。
- 単方向データフロー
- View→Action→Reducer→Store→View と一方向に流れる設計。変更経路が1本に定まる。
まとめ
状態管理の肝は、「View は state を直接さわらず、Action を発行するだけ」という一方通行のルールです。変更が必ず Reducer の1か所を通るおかげで、アプリがどれだけ大きくなっても「誰がいつ state を変えたか」を追いかけられます。図1で何度かボタンを押せば、同じサイクルがきれいに繰り返されるのが分かるはず——この規律こそが、複雑なUIを予測可能に保つ秘訣です。