我正在使用通量设计原则编写一个简单的应用程序，以更好地理解底层机制。为了提供增强的体验，用户更改会立即记录到本地存储，从而以零延迟更新界面。同时，向服务器分派一个异步请求；在服务器发生故障的情况下，本地存储将从服务器重新加载。
但是，我不确定如何最好地处理由于服务器响应缓慢而有多个异步请求待处理的情况。在这种情况下，处理故障似乎要复杂得多。例如，假设有三个待处理的异步请求（每个状态变化用户交互一个）。第一个成功了，第二个失败了。我应该取消第三个请求吗？如何从第二个请求而不是第三个请求回滚更改。
如果可能的话，我想避免这种复杂性。通量是否提供了一种机制来处理这种情况？我意识到我可以在异步请求挂起时锁定 UI，以防止多个请求排队，但我不愿意介绍这种方法会降低用户体验。
编辑：有些人相当质疑多个异步调用的问题是否特定于通量。我没有提到的是，我关注的是商店/调度员只执行同步代码 的指导。
好吧，正在问不同的问题。首先是如何管理状态变化的历史，其次是如何处理故障。
如何管理状态变化的历史
Facebook 不提供此类问题的解决方案。Flux 只是一种架构，而不是库或框架。但这是一个老问题，已经解决了很多次。基本方法是，只能通过对状态应用操作来更改状态，并且有可能取消或撤消每个操作。您可以为此使用Rx-Flux（但尚未完成），或者某些撤消/重做库可能会提供所需的功能。
如何处理失败
这种通用示例不能有通用解决方案。在某些情况下，您可以简单地吞下失败的操作并忘记它，在某些情况下，您将不得不重试操作直到它成功，在某些情况下，您必须要求用户执行某些操作才能解决问题。对于一些快节奏的游戏，将有一个解决方案，对于网上银行，我们将有另一个。
在我看来，问题不在于通量架构，而在于异步调用的实现。
假设您在获得用户交互状态更改后触发异步调用的当前实现。当您触发 AJAX 时，只能在客户端取消它，这意味着您调用abort来关闭响应的侦听器。但现在在服务器端，第三个请求仍将继续。
除非您实现 >> 每个用户交互状态更改将存储一个队列（可能是一个数组）的方式......然后您一个接一个地触发 AJAX 调用。
如果您可以提供任何代码片段，将会更好地理解/解释:)