Question

enter image description here

据我所知，这张图片是大多数（如果不是全部）Flux程序员的终极指南。考虑到这一点，我有几个问题：

在我的 Web API Utils 中进行所有$.ajax次调用是否正确/强烈建议？
- 回调调用动作创建者，传递过程中的数据
如果我希望商店进行 AJAX通话，我必须先调用 Action Creator ，对吗？直接从商店调用 Web API Utils 中的函数是否根本不正确？
是否有从商店连接到动作创建者的虚拟单边箭头？
- 我有很多不通过视图的操作
调度程序与商店之间的回调是什么？
这里的 Web API 是什么？这是您应用RESTful API的地方吗？在某个地方有这样的例子吗？

在我的动作创建器中，是否可以使用逻辑（知道哪些操作要发送）？基本上，此操作接收来自我的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;
            ...
        }
    }
}

我在网上看到了很多不同的答案，但我仍然不确定如何将所有这些答案合并到我的应用程序中。 TYIA！

Answer 1

在我的Web API Utils中调用所有$ .ajax调用是否正确/强烈建议？回调调用动作创建者，在过程中传递数据。

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

前段时间我写了一篇博客文章，展示了如何处理请求http://www.code-experience.com/async-requests-with-react-js-and-flux-revisited/

的方法

如果我希望我的商店进行AJAX调用，我必须先调用Action Creator，对吧？从Store直接调用Web API Utils中的函数是否根本不正确？

这是一个很好的问题，就我所见，每个人都有一点不同。 Flux（来自Facebook）没有提供完整的答案。

这里通常有两种方法：

你可以提出一个商店不应该问的问题＆＃34;对于任何数据，只需简化摘要操作并通知视图。这意味着你必须解雇＆＃34; fetch＆＃34;如果商店为空，则在组件内执行操作。这意味着如果必须获取数据，则必须检查每个数据监听视图。如果多个视图收听同一商店，则可能导致代码重复。
商店是＆＃34;聪明＆＃34;从某种意义上说，如果他们被要求提供数据，他们会检查他们是否确实有交付状态。如果他们不这样做，他们会告诉API Utils获取数据并将待处理状态返回给视图。

请注意，这＆＃34;告诉API获取数据＆＃34;不是一个基于回调的操作，而是一个＆＃34; fire and forget＆＃34;一。一旦请求返回，API将分派操作。

我更喜欢选项2到选项1，我听说Facebook团队的Bill Fisher说他们也是这样做的。（见上文博文中某处的评论）

所以没有在我看来直接从商店调用Api并不是根本错误。

是否有从Store到Action Creators连接的虚拟单面箭头？

根据您的Flux实施情况，可能会很好。

Dispatcher和Store之间有什么回调？

它们是唯一可以实际改变商店状态的功能！每个商店都向Dispatcher注册一个回调。无论何时调度操作，都会调用所有回调。每个回调决定是否必须在给定操作类型的情况下改变商店。一些Flux库试图隐藏这个实现细节。

这里的Web API是什么？这是您应用RESTful API的地方吗？在某个地方有这样的例子吗？

我认为在图片中，Web API矩形代表实际的服务器，API Utils是调用服务器的那些（即$ .ajax或superagent）。它很可能是一个服务于JSON的RESTful API。

一般建议：

Flux是一个相当宽松的概念，确切的实施方式会因团队而异。我注意到Facebook也随着时间的推移在这里和那里改变了一些方法。确切的周期没有严格定义。有一些相当＆＃34;固定＆＃34;事情虽然：

有一个Dispatcher会将所有操作分派到所有商店，并且当时只允许一个操作来阻止事件链地狱。
商店是行动接收者，必须通过行动改变所有州。
行动是＆＃34;火灾和忘记＆＃34; （没有回调！）
视图从商店接收状态并触发操作

其他方面的做法与实施不同

Answer 2

在我的Web API Utils中调用所有$ .ajax调用是否正确/强烈建议？回调调用动作创建者，在过程中传递数据。

绝对

如果我希望我的商店进行AJAX调用，我必须先调用Action Creator，对吧？从Store？
直接调用Web API Utils中的函数是否根本不正确？

首先，问问自己为什么您的商店需要进行API调用。我能想到的唯一原因是你想要在商店中缓存收到的数据（我这样做）。

在最简单的Flux实现中，所有Actions仅从View和Server创建。例如，用户访问＆＃34;个人资料＆＃34;视图，视图调用profileRequest操作创建者，调用ApiUtils，输入一些数据，创建ServerAction，ProfileStore更新自身和{{1相应地做了。

使用缓存：ProfileView向ProfileView询问某个配置文件，商店没有它，因此返回一个空状态，其中包含州＆＃39; loading＆＃39;和调用ProfileStore来获取该配置文件（并忘记它）。通话结束后，将创建ApiUtils，ServerAction将自行更新等。这样可以正常工作。你也可以从商店打电话和ActionCreator，但我看不到这个好处。

MartyJS做了类似的事情。一些通量实现对承诺也是如此。

我认为重要的部分是：当数据重新进入系统时，会使用新数据调用ServerActionCreator。然后流回商店。

我认为商店应该只查询数据，所有状态改变动作（更新内容）都应该由用户启动（来自视图）。来自Facebook的工程师在这里写到：https://news.ycombinator.com/item?id=7719957

是否有从Store到Action Creators连接的虚拟单面箭头？

如果您希望您的商店变得聪明：是的。如果你想让你的应用变得简单：不，请浏览视图。

Dispatcher和Store之间有什么回调？

这些是您在商店中找到的调度处理程序。调度员触发一个动作，商店听取这个火灾事件并对动作/有效负载做一些事情。

这里的Web API是什么？这是您应用RESTful API的地方吗？在某个地方有这样的例子吗？

这是你的ajax调用的地方。通常这意味着一些REST API，但也可能是websockets或其他什么。我一直很喜欢这个教程：http://fancypixel.github.io/blog/2015/01/29/react-plus-flux-backed-by-rails-api-part-2/

免责声明：这些是我对Flux的解释。 Flux本身并没有真正解决获取数据的问题，这就是为什么他们在FB上提出Relay and GraphQL的原因

Flux最佳实践：存储调度操作，Web API Utils中的AJAX调用？

2 个答案: