2015/11/06私がReact/Fluxアプリケーションを書いてきて、もう1年になる。Flux開発の1年を振り返ってみると、このFluxというものが便利だと、はっきり言うことができる。過去は「こんなイベントチェーンなんて触ってないよ」という日々だった。取り組んできた全てのFluxコードベースは綺麗だったし、デバッグ可能で、メンテナンスも容易にできた。Fluxに関しては、インタラクティブな金融チャート、リアルタイムのテーブル絞込み、いつものCRUD系のものから複雑な非同期要求チェーンにいたるまで、遭遇してきたあらゆる問題を解決することができた。Flux最大の長所の一つは、その普遍性だ。絶対的に簡潔で美しくなることは決してないが、決してハッキングすることもない。大規模コードベースにおいては良いことだ。複雑なUIに取り組む際にも、同じ考え方を当てはめると非常に効果的となる。良いことづくめ?もちろん、そんなことはない。思い通りに動くFluxコードを書くのは難しすぎると、私も再三気づかされてきた。あるアクションを起こすと、残念ながら、それが複数ストアへの書き込みをトリガしてしまう。一つのストア内のどこかで、そのアクションへの処理を忘れてしまうか、またはその他どこかのストアでwaitFor(実行可能までの待機)をしそびれてしまう。これで、ほぼいつもテストスイートを掻い潜ってしまうし、コードレビューをすり抜けてしまうこともたびたび起こる。これは大抵、極めて特殊なケースなので、恐らく製作中にミスがうまく解決されることはないだろう。waitForは非常にややこしくなりがちだ。これに関する問題を持ち掛ける人は他にもいる。waitForなしでも、複雑な記述にはたびたびバグが発生する。アクションにトリガされた複雑な状態更新は、FluxとReact関連で事実上最も避けるべきことだ。(“Reducers”)」がReactコミュニティでヒットしている。Abramov氏によって有名になった。Weiss氏がリデューサーについて書いた記事もある(あなたがFluxのリデューサーをよく知らないなら、今リデューサーについてざっと読んでからこの記事に戻ってきてほしい)。私はリデューサーのコンセプトがすごく好きだ。エレガントで、標準のストアインスタンスより多くの点において優れている。実装された例を見てみると、上の方で私が述べた欠点は、部分的ではあるがなくなってしまった。それがどういうことか説明するために、なぜwaitForに問題があるのか明確に述べてみよう。開発者としては、状態の更新順序を次から次へと明確に宣言したい。多重モジュールに宣言の順番を分割したくない。waitForのやり方では、「これはこれの前に起こるべきだ」と常に考える必要があり、骨が折れる。ステートメントを一行下に書くだけでは演算順序を宣言できないのは非常に残念なことだ。(皮肉なことに、それはまさにFluxがすべての更新を極小のアクションや、同期処理が必要なアクションに分けてしまう理由だ)例えばReduxにおいては、リデューサーを使うことでこれが可能になるのだが、ここでは完全な解決策にはならない。私は直感的に状態の更新順序を宣言したが、それだけでは足りない。開発者としては、アクションをトリガするあらゆる状態の更新を概観したいのだ。一か所のコードで、各行ごとに。コード内のどこかに包括的な概要を持っておくことは、正常な状態更新を行える可能性を最大化する。書き込み条件の順序が重要視される場面では特に!これまで私が見てきたあらゆるFluxの実装においては、アクションタイプによってグレップしなければならず、複雑な書き込み条件を理解するために、恐らく複数のファイルに目を通さなければならない。気にかけていないアクションにも目を通す必要があるだろう。開発者にとってもコードレビューをする人にとっても、そんな最低なことは尚更したくない。私のプロジェクトでは、ミスの大きな原因は、分散されて書かれたアクションだった。今日現在のFluxがストアまたはアクション関係マトリックスを間違った軸上に分けているのだと思う。状態の一部に作用するあらゆるアクションは容易にわかるが、一つのアクションが作用する状態をすべて見つけ出すのは難しい。私の意見では、その逆であるべきだ。当然のことながら、開発者は何よりもまず、極小の観点から考えるものだと思う。彼はアクションを次から次へと実装しながら、そのアクションがどの状態の更新を引き起こすかを考えている。私が、どのアクションが状態のどの時に作用するかを調べることができる場合、あなたはそれほど得るものがない。あなたのアクションが状態にどのような更新をしたのか、ぜひとも全体を見渡したくはないだろうか?それは機能を実装している時やコードレビューの時には尚更、目に飛びついてくるはずのものだ。それは、私がこれまでに見てきたどのFluxアプリにもないだろう。書き込み条件にビジネスロジックが含まれているため、誰もが小規模なストアまたはリデューサーを書く傾向がある。整理された状態を保つために、コードを小さい別々のモジュールに分けたいと思うだろう。小規模な状態処理モジュールというのは、いくつかのアクションがそのモジュール内の多くで処理されることを意味し、あなたは、「このアクションは何を徹底的に起こすのだろう?」とたびたび自分に問いかけることになる(たとえ書き込む順序はどうでもいいとしても)。私の見てきた限り、皆小さな状態の一部分を処理するリデューサーを書くが、それは同時に、昔からのFluxのストアのように、可能な限りありとあらゆるアクションでもある。