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