javascript - Flux 最佳实践 : Stores dispatching actions, Web API Utils 中的 AJAX 调用？

Question

据我了解，此图已成为大多数(如果不是全部)Flux 程序员的终极指南。考虑到这个流程，我有几个问题:

1. 将我所有的 $.ajax 调用都放在我的 Web API Utils 中是否正确/强烈建议？
   • 回调调用 Action 创建者，传递过程中的数据
2. 如果我想让我的Store 进行AJAX 调用，我必须先调用Action Creator，对吗？直接从 Store 调用 Web API Utils 中的函数是否根本不正确？
3. 从 Store 到 Action Creators 是否有一个虚拟的单向箭头？
   • 我有很多操作不经过 View
4. Dispatcher 和 Store 之间的回调是什么？
5. 这里的Web API是什么？这是您应用 RESTful API 的地方吗？有这样的例子吗？

6. 在我的Action Creator 中包含一个逻辑(知道要调度哪个Action)是否可以？基本上，此操作接收来 self 的 AJAX 调用的响应。这是一个片段:

   var TransportActions = {
       receiveProxyMessage: function (message, status, xhr) {
           switch (message) {
               case ProxyResponses.AUTHORIZED:
                   AppDispatcher.dispatch({
                       type: ActionTypes.LOGIN_SUCCESS,
                       reply: m
                   });
                   break;
               case ProxyResponses.UNAUTHORIZED:
                   AppDispatcher.dispatch({
                       type: ActionTypes.LOGIN_FAIL,
                       reply: m
                   });
                   break;
               ...
           }
       }
   }
   

我在网上看到了很多不同的答案，但我仍然不确定如何将所有这些答案合并到我的申请中。蒂亚!

Answer 1

Is it correct/highly advisable to have all of my $.ajax calls inside my Web API Utils? Callbacks call the action creators, passing the data in the process.

是的，您应该将所有请求放入一个实体中，即 Web API Utils。他们应该发送响应，以便任何商店都可以选择对其采取行动。

我不久前写了一篇博文，展示了一种处理请求的方法 http://www.code-experience.com/async-requests-with-react-js-and-flux-revisited/

If I want my Store to make an AJAX call, I do have to call the Action Creator first, right? Is it fundamentally incorrect to call a function in Web API Utils directly from Store?

这是一个很好的问题，据我所知，每个人的做法都略有不同。 Flux(来自 Facebook)没有提供完整的答案。

这里通常有两种方法:

1. 您可以提出这样的论点，即 Store 不应“询问”任何数据，而是简单地消化操作并通知 View 。这意味着如果商店为空，您必须在组件内触发“获取”操作。这意味着您必须检查每个数据监听 View 是否必须获取数据。如果多个 View 监听同一个 Store，这可能会导致代码重复。

2. 从某种意义上说，商店是“智能”的，如果他们被要求提供数据，他们会检查他们是否真的有状态要交付。如果他们不这样做，他们会告诉 API Utils 获取数据并将挂起状态返回给 View 。

   请注意，这个“告诉 API 获取数据”不是基于回调的操作，而是“即发即弃”操作。一旦请求返回，API 将调度操作。

与选项 1 相比，我更喜欢选项 2，而且我听 Facebook 团队的 Bill Fisher 说他们也是这样做的。 (请参阅上面博文中某处的评论)

所以不在我看来，直接从 Store 调用 Api 从根本上来说并不是错误的。

Is there like a virtual one-sided arrow connecting from Store to Action Creators?

根据您的 Flux 实现，很可能会有。

What are the Callbacks between Dispatcher and Store?

它们是唯一可以真正改变商店状态的函数!每个 Store 都会向 Dispatcher 注册一个回调。每当分派(dispatch)操作时，都会调用所有回调。每个回调决定它是否必须改变给定操作类型的商店。一些 Flux 库试图向您隐藏此实现细节。

What's the Web API here? Is this where you'd apply a RESTful API? Is there an example of this somewhere?

我认为图片中的 Web API 矩形代表实际的服务器，API Utils 是调用服务器的工具(即 $.ajax 或 superagent)。它很可能是一个提供 JSON 的 RESTful API。

一般建议:

Flux 是一个相当松散的概念，具体的实现因团队而异。我注意到 Facebook 也随着时间的推移改变了一些方法。确切的周期没有严格定义。虽然有一些非常“固定”的东西:

1. 有一个 Dispatcher 可以将所有操作发送到所有存储并且一次只允许一个操作以防止事件链 hell 。
2. Stores 是 Action 接收器，所有状态都必须通过 Action 来改变。
3. 操作是“即发即弃”(无回调!)
4. View 从商店接收状态并触发操作

其他的事情在不同的实现中都是不同的