Fluxアーキテクチャに関するFacebookの講演で、Jingは 12:17 、現在のアクションがストアによって完全に処理されるまで、ディスパッチャはアクションをディスパッチできないように強制していると述べています。
ここのディスパッチャは、カスケード効果がないことを強制する主要な部分です。アクションがストアに入ると、ストアがそれを完全に処理し終えるまで、別のアクションを入れることはできません。
それでは、私の質問は、ストアから開始される可能性のある長時間実行の非同期操作(Ajaxリクエストやその他の外部非同期APIの処理など)をどのように適切に処理するかです。これは、アクションディスパッチの完了をブロックするものです。 (たとえば、Ajaxリクエストの結果でpromiseの解決を待機している)と、UIで生成されたユーザーからのアクションがディスパッチされないようにすることができます。
私の理解では、Ajaxなどに依存する非同期アクションは、アクションがすべてのサブスクライバーにディスパッチされるのをブロックするべきではありません。
TodoMVCの例のTODO_UPDATE_TEXT
のような、ユーザーアクション用の個別のアクションと、サーバーが戻ったときに呼び出されるTODO_UPDATE_TEXT_COMPLETED
のようなアクション(または、最新の属性の新しいコピーを含むTODO_UPDATE_COMPLETED
のようなより一般的なアクション)があります。 。
楽観的な更新を実行して、変更の影響をユーザーにすぐに表示する場合は、ユーザーのアクションに応じてストアをすぐに更新できます(その後、サーバーが信頼できるデータを返したときにもう一度)。サーバーで待機する場合は、サーバーによってトリガーされたアクションに応答してのみストアを更新することができます。
Sophieが非同期データを処理する このfluxxorの例 で説明していることの実装を参照してください。ネガティブな点は、このアプローチに従うと、各ユーザーインタラクションには3つのアクション(トリガー、成功、失敗)が必要ですが、すべてのユーザーインタラクションにこの楽観的なアプローチが必要なわけではないということです。
重要な部分はアクションにあります:
loadBuzz: function() {
this.dispatch(constants.LOAD_BUZZ);
BuzzwordClient.load(function(words) {
this.dispatch(constants.LOAD_BUZZ_SUCCESS, {words: words});
}.bind(this), function(error) {
this.dispatch(constants.LOAD_BUZZ_FAIL, {error: error});
}.bind(this));
},
BinaryMuse(fluxxorcreator)はLOAD_BUZZアクションをディスパッチしてから、成功または失敗関数を使用して非同期要求をトリガーし、成功または失敗アクションをディスパッチします。ストアは、楽観的な更新のためにLOAD_BUZZアクションをリッスンするか、svg読み込みアイコンを表示してから、成功またはエラーの最終通知のために成功およびエラーアクションをリッスンできます(さらに、BUZZWORDをストアに保存します)。
onLoadBuzz: function() {
this.loading = true;
this.emit("change");
},
onLoadBuzzSuccess: function(payload) {
this.loading = false;
this.error = null;
this.words = payload.words.reduce(function(acc, Word) {
var clientId = _.uniqueId();
acc[clientId] = {id: clientId, Word: Word, status: "OK"};
return acc;
}, {});
this.emit("change");
},
Sophieのように、ajaxリクエストは、アクションのディスパッチをブロックするべきではないと思います。これは、サーバーへの同期リクエストに似ており、ページの応答性に影響を与えるためです。