メインコンテンツへスキップ
非公式ベータ版翻訳

このページは PageTurner AI で翻訳されました(ベータ版)。プロジェクト公式の承認はありません。 エラーを見つけましたか? 問題を報告 →

動機

JavaScriptシングルページアプリケーションの要件がますます複雑になるにつれ、私たちのコードはこれまで以上に多くのステートを管理する必要が生じています。このステートにはサーバー応答やキャッシュされたデータ、さらにサーバーに永続化されていないローカルで生成されたデータが含まれます。UIステートの複雑さも増しており、アクティブなルートや選択されたタブ、スピナー、ページネーションコントロールなどを管理する必要があります。

この絶えず変化するステートの管理は困難です。あるモデルが別のモデルを更新し、ビューがモデルを更新し、それがさらに別のモデルを更新し、最終的には別のビューが更新される可能性があります。やがて、ステートの「いつ」「なぜ」「どのように」を制御できなくなり、アプリケーションで何が起きているのか理解できなくなります。システムが不透明で非決定的になると、バグの再現や新機能の追加が困難になります。

さらに悪いことに、フロントエンド製品開発で一般的になりつつある新たな要件を考えてみましょう。開発者には楽観的更新(optimistic updates)やサーバーサイドレンダリング、ルート遷移前のデータ取得などが求められます。私たちはこれまで経験したことのない複雑さを管理しようとしており、必然的にこう問わざるを得ません: もう諦めるべきか? 答えは ノー です。

この複雑さは、人間の思考が苦手とする2つの概念が混在しているため扱いが難しいのです: ミューテーション(変更)と非同期性です。私はこれをメンタスとコーラと呼んでいます。それぞれ単体では優れていますが、組み合わせると混乱を招きます。Reactのようなライブラリは、非同期処理と直接的なDOM操作を排除することでビューレイヤーの問題解決を試みます。しかしデータのステート管理は依然として開発者に委ねられており、ここにReduxが登場します。

FluxCQRSイベントソーシングの流れを継承し、Reduxはステートのミューテーションを予測可能にすることを目指しています。これは更新が「どのように」「いつ」発生するかについて特定の制約を課すことで実現されます。これらの制約はReduxの3つの原則に反映されています。