4

我们正在重构一个大型 Backbone 应用程序以使用 Flux 来帮助解决一些紧密耦合和事件/数据流问题。但是，我们还没有弄清楚如何处理需要知道特定 ajax 请求状态的情况

当控制器组件从通量存储请求一些数据，并且该数据尚未加载时，我们触发 ajax 请求来获取数据。我们在发起请求时调度一个动作，在成功或失败时调度另一个动作。

这足以加载正确的数据，并在加载数据后更新存储。但是，在某些情况下，我们需要知道某个 ajax 请求是挂起还是完成 - 有时只是为了在一个或多个视图中显示微调器，或者有时在加载数据之前阻止其他操作。

人们在通量/反应应用程序中使用这种行为的任何模式吗？以下是我考虑过的几种方法：

  1. 拥有一个“请求状态”存储，它知道是否存在任何类型的未决、已完成或失败的请求。这适用于简单的情况，例如“是否有未决的锻炼数据请求”，但如果我们想要更细化“是否有未决的锻炼 id 123 请求”，则变得复杂

  2. 让所有商店跟踪相关数据请求是否处于待处理状态，并将该状态数据作为商店 api 的一部分返回 - 即 WorkoutStore.getWorkout 将返回类似 { status: 'pending', data: {} } 的内容。这种方法的问题在于，这种状态似乎不应该与域数据混合，因为它确实是一个单独的问题。此外，现在锻炼商店 api 的每个消费者都需要处理这种“状态响应”，而不仅仅是相关的域数据

  3. 忽略请求状态 - 数据存在且控制器/视图对其进行操作，或者数据不存在且控制器/视图不对其进行操作。更简单，但可能不足以满足我们的目的

4

1 回答 1

3

这个问题的解决方案根据应用程序的需要而有很大的不同，我不能说我知道一个万能的解决方案。

通常，#3 很好，你的 React 组件只是根据 prop 是否为空来决定是否显示微调器。

当您需要更好地跟踪请求时，您可能需要在请求本身级别进行此跟踪，或者您可能需要在正在更新的数据级别进行此跟踪。这是两种不同的需求，需要相似但略有不同的方法。两种解决方案都使用客户端 id 来跟踪请求，就像您在 #1 中描述的那样。

如果调用动作创建者的组件需要知道请求的状态，你可以创建一个 requestID 并在 this.state 中保留它。稍后，该组件将检查通过 props 向下传递的请求集合，以查看 requestID 是否作为键存在。如果是这样，它可以在那里读取请求状态，并清除状态。RequestStore 听起来像是存储和管理该状态的好地方。

但是，如果您需要在特定记录级别了解请求的状态，一种管理方法是让存储中的记录同时保留 clientID 和更规范的（服务器端）id。这样，您可以创建 clientID 作为乐观更新的一部分，当响应从服务器返回时，您可以清除 clientID。

我们在 Facebook 的几个项目中使用的另一个解决方案是创建一个操作队列作为商店的附件。动作队列是第二个存储区。您的所有 getter 都从存储本身和操作队列中的数据中提取。因此，在服务器返回响应之前，您的乐观更新实际上不会更新商店。

于 2014-12-13T14:14:03.093 回答