我正在寫一個簡單的應用程序，使用通量設計原則來更好地理解底層機制。爲了提供增強的體驗，用戶更改會立即記錄到本地商店，從而以零延遲更新界面。同時，異步請求被分派給服務器;在發生服務器故障時，本地存儲將從服務器重新加載。通量：如何處理多個異步請求
但是，我不確定如何最好地處理這種情況，在這種情況下，由於服務器響應較慢，有多個異步請求處於待處理狀態。在這種情況下處理失敗似乎要複雜得多。例如，假設有三個掛起的異步請求（每個狀態一個用於突變用戶交互）。第一個成功，但第二個失敗。我應該取消第三個請求嗎？我如何從第二個請求回滾更改，但不是第三個。
我想盡可能地避免這種複雜性。流量是否提供了處理這種情況的機制？我意識到我可以在異步請求掛起時鎖定用戶界面，以防止來自排隊的多個請求，但我不願意介紹這種方法的降級用戶體驗。
編輯： 有些人相當質疑是否多個異步調用的問題是特定於通量。我沒有提到的是，我關心的是guidance，存儲/調度程序只執行同步代碼。
那麼，正在問不同的問題。首先是如何管理國家變化的歷史，其次是如何處理失敗。
如何管理變化的歷史狀態
Facebook並沒有提供這樣的問題的解決。 Flux只是一個架構，而不是一個庫或框架。但這是一個多次解決的老問題。基本方法是，該狀態只能通過對狀態進行操作才能更改，並且可能會取消或撤消每個操作。您可以使用Rx-Flux（但尚未完成），因爲此撤消/重做庫可能會提供所需的功能。
如何處理失敗
不能有這樣的通用例如一個通用的解決方案。在某些情況下，您可以簡單地吞下失敗的操作並忘記操作，在某些情況下，您必須重試操作直至成功，在某些情況下，您必須要求用戶執行某些操作才能解決問題。對於一些快節奏的遊戲，將會有一種解決方案，對於網上銀行我們會有另一種解決方案。
聽起來這個問題不是關於通量架構，而是關於異步調用的實現。
假設一旦您獲得用戶交互狀態更改，就會觸發異步調用的當前實現。當你觸發AJAX時，只能在客戶端取消它，這意味着你調用abort來關閉響應的監聽器。但是現在在服務器端，第三個請求仍將繼續。
除非你實現的方式>>每個用戶交互狀態的改變都會存儲一個隊列（可能是一個數組）。然後你一個接一個地觸發AJAX調用。
會理解/解釋更好，如果你能提供任何代碼片段:)
除了是一個不好的用戶experienec，爲了防止在同時發生多個異步操作的情況下阻塞UI是一個壞的代碼味道。 這是一種耦合形式;您從視圖外部（即在Action Creator中）對視圖做出假設。 – namuol