モチベーション

シングルページアプリケーションとしてのJavaScriptの必要性が増してきています。そのため私たちのコードはかつてないほど多くの状態を管理しなければなりません。状態には、サーバーからの応答やキャッシュデータが含まれます。ローカルで作られて、まだサーバーと整合が取れていないデータも状態です。 UIの状態は、複雑性を増しています。動的ルート、タブ選択、スピナー、ページネーション（ページ繰り）の制御なども管理しないといけません。

この変わり続ける状態を管理するのは、大変です。もしモデルが別のモデルを更新するなら、ビューがモデルを更新することもあり得ます。そしてそれが別のモデルを更新するかもしれません。それが今度は、別のビューの更新を引き起こすかもしれません。どこかの時点で、もはやアプリで何が起こっているのか分からなくなります。いつ、なぜ、どのように状態が変わるのか制御できなくなってしまうのです。システムが不明瞭で予見不能だと、バグを再現したり新しい機能を追加するのが難しくなります。

さらに、フロントエンドの製品開発で新たな要件が一般的になりつつあります。開発者として、楽観更新（訳注：非同期処理が成功するという前提で、サーバーの応答を待たずにフロントを更新すること）やサーバーサイドレンダリング、ルート遷移前のデータ取得などへの対処を求められています。

かつてない複雑性を管理しようとしていることに気づかされ、この質問をせずにはいられません： 諦めるときなのか？ (is it time to give up?) その答えは、Noです。

この複雑性に対処するのが難しい理由は、2つの概念をごちゃ混ぜにしているから です。その2つとは、人間にとって理解するのが難しい 変更と非同期性 です。 私はこれを、メントスとコーラ (Mentos and Coke)と呼んでいます。別々だと素晴らしい。でも一緒にすると、めちゃくちゃになる。 Reactのようなライブラリは、この問題をビュー層で解決しようと試みています。解決方法は、非同期性と直接的なDOM操作の両方を取り除くことです。しかし、データの状態管理は開発者任せです。ここに、Reduxの入る余地があります。

Flux、 CQRS、 そしてEvent Sourcingというステップに従い、 Reduxは状態変化を予測可能にしようと試みています。 具体的には、どのように、またいつ更新が起きるかについて一定の制限を課します。これらの制限は、Reduxの３つの原則に反映されています。