Reduxまとめ（１）

Redux/ˈriːdʌks/

以下全訳ではなく、要約です。自分なりにReduxについて分かりやすい言葉でまとめておきます。適当な日本語訳がない場合や、日本語に訳すとわかりにくくなると判断した語はそのまま使っています。誤訳・分かりにくいところがありましたらコメントでフィードバックをください。


Motivation

JavaScriptのシングルページアプリケーションではサーバーレスポンスやキャッシュしたデータ、あるいはサーバーにまだ渡していないローカルに作られたデータそれぞれのstateを管理するが、これはとても複雑だ。たとえば、モデルが別のモデルを更新することができるなら、ビューはその別のモデルを更新できるモデルを更新できるし、今度はそのモデルは別のビューを更新するかもしれない。stateがいつ、どうして、どのようにして更新されるのかコントロールを失ってしまっては、自分のアプリの中で何が起こっているのか、もはや理解することができない。

開発者は最適なアップデート、サーバーサイド・レンダリング、ルーティング前のデータフェッチ等、フロントエンド開発において一般的になるこれら新しい技術を扱うことを求められている。私たちは、今まで出会ったこともない複雑さに直面しているのだ。では、どうする？諦める？その答えは、ノーだ。

この複雑さは、変化(mutation)と非同期性(asynchronicity)を混交することにある。これはメントスとコーラのようなもので、それぞれは素晴らしいものなのだが、混ぜると、ごちゃついてしまう。Reactのようなライブラリは非同期性とDOM操作を取り除くことで、ビューレイヤーにおけるこの問題の解決を狙う。しかし、データのstate管理は開発者に任される。そこにReduxが入り込む。
MentosAndCoke

Flux、CQRS、Event Sourcingを踏まえ、Reduxはどのように、あるいは、いつ、更新が起こるかに対し、特定の制限を課すことで、stateの変化に予測をつけようとしている。この制限はReduxの３つの原則に反映されている。

Three Principles

Single Source Of Truth (SSOT)

アプリケーション全体のstateは一つのstoreの中のオブジェクトツリーに保存される。

State is read-only

stateを変更する唯一の方法はactionのemit

Changes are made with pure functions

stateツリーがどのようにactionによって変形するのかreducersを使い指定する

Prior Art

Flux

Fluxのように、Reduxはモデルの更新ロジックを特定のレイヤーにおくことを規定している。つまりFluxのstoreであり、reduxのreducersである。ソースコードが直接データの変更を叩く代わりに、FluxとReduxはともに、actionと呼ばれるプレーンオブジェクトに変更を記述する。

Fluxとは異なり、ReduxはDispatcherの概念を持たない。これはFluxがevent emittersの代わりにピュア関数を用いるためであり、ピュア関数のおかげでFluxアーキテクチャを引き継ぎつつも、より簡単な記述が可能になる。

もう一つ重要なFluxとの違いは、Reduxはデータを開発者が変更しないと想定していることだ。stateに対し、プレーンなオブジェクトや配列を用いるのはいい。しかし、reducers内において、stateを変更することは推奨されない。ES7のobject spread syntaxとBabelを用いて、新しいオブジェクトで返すべきだ。

技術的には、データを変更する"ピュアでない"reducersを書くことは可能ではあるが、time travel、record/replay、hot reloadingといった開発上の特徴は機能しなくなってしまう。

Elm
Immutable
Baobab
Rx

Ecosystem

Tutorials and Articles