基礎となるメカニズムをよりよく理解するために、フラックス設計の原則を使用して簡単なアプリケーションを作成しています。強化されたエクスペリエンスを提供するために、ユーザーの変更はローカル ストアにすぐに記録されるため、ゼロ レイテンシーでインターフェイスが更新されます。同時に、非同期リクエストがサーバーにディスパッチされます。サーバーに障害が発生した場合、ローカル ストアはサーバーから再ロードされます。
ただし、サーバーの応答が遅いために複数の非同期要求が保留されているシナリオを処理する最善の方法がわかりません。このようなシナリオでは、障害への対処ははるかに複雑に見えます。たとえば、保留中の非同期リクエストが 3 つあるとします (ユーザー インタラクションを変更する状態ごとに 1 つ)。最初は成功しますが、2 番目は失敗します。3 番目の要求をキャンセルする必要がありますか? 3 番目のリクエストではなく、2 番目のリクエストからの変更をロールバックするにはどうすればよいですか。
できればこの種の複雑さは避けたいと思います。フラックスはそのようなシナリオに対処するメカニズムを提供しますか? 複数のリクエストがキューに入るのを防ぐために、非同期リクエストが保留されている間に UI をロックできることはわかっていますが、そのようなアプローチのユーザー エクスペリエンスの低下を紹介するのは嫌です。
編集: 複数の非同期呼び出しの問題がフラックスに固有のものであるかどうかについて、かなり疑問視する人もいます。私が言及しなかったのは、私の懸念は、ストア/ディスパッチャーが同期コードのみを実行する というガイダンスに固有のものであるということです。