我们正在重构一个大型Backbone应用程序，以使用Flux来帮助解决一些紧密耦合和事件/数据流问题。但是，我们还没有弄清楚如何处理需要了解特定ajax请求状态的案例
当控制器组件从磁带存储器请求某些数据，并且尚未加载该数据时，我们会触发ajax请求来获取数据。我们在发起请求时发送一个动作，在成功或失败时发送另一个动作。
这足以加载正确的数据，并在加载数据后更新存储。但是，我们在某些情况下需要知道某个ajax请求是挂起还是已完成 - 有时只是为了在一个或多个视图中显示微调器，或者有时在加载数据之前阻止其他操作。
在流量/反应应用程序中，是否存在人们用于此类行为的任何模式？以下是我考虑过的一些方法：
拥有“请求状态”＆＃39;知道是否存在任何类型的待处理，已完成或失败的请求的存储。这适用于简单的情况，例如，是否存在针对锻炼数据的待处理请求，但如果我们想要更加细化，那么会变得复杂吗？是否有针对锻炼ID 123的待处理请求<＆＃39; < / p>
让所有商店跟踪相关数据请求是否挂起，并将该状态数据作为商店API的一部分返回 - 即WorkoutStore.getWorkout将返回类似{status：＆＃39; pending＆ ＃39;，数据：{}}。这种方法的问题在于，似乎这种状态不应该与域数据混合在一起，因为它实际上是一个单独的问题。此外，现在锻炼商店api的每个消费者都需要处理这种状态＆＃39;而不仅仅是相关的域数据
忽略请求状态 - 数据存在且控制器/视图对其起作用，或者数据不在那里且控制器/视图不对其起作用。更简单，但可能不足以达到我们的目的
答案 0 :(得分：3)
这个问题的解决方案根据应用程序的需求而有很大差异，我不能说我知道一个通用的解决方案。
通常，＃3很好，你的React组件只是根据prop是否为null来决定是否显示一个微调器。
当您需要更好地跟踪请求时，您可能需要在请求本身级别进行此跟踪，或者您可能需要在正在更新的数据级别上进行此跟踪。这是两种不同的需求，需要类似但略有不同的方法。两种解决方案都使用客户端ID来跟踪请求，就像您在＃1中所描述的那样。
如果调用操作创建者的组件需要知道请求的状态，则创建一个requestID并挂起this.state中的那个。稍后，该组件将检查通过props传递的请求集合，以查看requestID是否作为键存在。如果是这样，它可以读取那里的请求状态，并清除状态。 RequestStore听起来像是存储和管理该状态的好地方。
但是，如果您需要知道特定记录级别的请求状态，管理此方法的一种方法是让您在商店中的记录同时保留clientID和更规范（服务器端） ） ID。这样，您可以将clientID作为乐观更新的一部分创建，当响应从服务器返回时，您可以清除clientID。
我们在Facebook的一些项目中使用的另一个解决方案是创建一个动作队列作为商店的附件。动作队列是第二个存储区域。所有的getter都从商店本身和动作队列中的数据中抽取。因此，在响应从服务器返回之前，您的乐观更新实际上不会更新存储。