私は最近、React と Flux アーキテクチャで遊んでいます。
2 つのストア A と B があるとします。A は B からの値を必要とするため、B に依存しています。したがって、ディスパッチャーがアクションをディスパッチするたびに、最初に B.MethodOfB が実行され、次に A.MethodOfA が実行されます。
A を B のリスナーとして登録し、B が変更イベントを発行するたびに A.MethodOfA を実行するよりも、このアーキテクチャの利点は何ですか?
ところで: Facebook のサンプル ディスパッチャの「スイッチ ケース」を使用しない Flux 実装について考えてみてください。
イベント化されたアプローチの問題は、どのハンドラーが特定のイベントを最初に処理するかについての保証がないことです。そのため、非常に大規模で複雑なアプリでは、これが絡み合った Web になり、いつ何が起こっているのかがよくわからなくなり、ストア間の依存関係の管理が非常に困難になります。
コールバックベースのディスパッチャの利点は 2 つあります。ストア自体が更新される順序は、この順序付けが必要なストアで宣言されます。また、意図したとおりに正確に動作することが保証されます。そして、これが Flux の主な目的の 1 つであり、アプリの状態を予測可能で、一貫性があり、安定したものにすることです。
時間の経過とともに成長したり変化したりしないことが保証されている非常に小さなアプリでは、あなたの提案に異議を唱えることはできません. しかし、小さなアプリは最終的には大きなアプリになる傾向があります。これは、多くの場合、それが起こっていることに気付く前に発生します。
Flux には確かに他のアプローチがあります。かなりの数の異なる実装が作成されており、この問題に対するアプローチが異なります。ただし、これらの実験のどれがうまくスケールするかはわかりません。一方、Facebook の Flux レポジトリのディスパッチャーとドキュメントに記載されているアプローチは、真に巨大なアプリケーションに拡張され、十分にテストされています。