React-native Redux 业务逻辑应该在 action 还是 reducer 中答案

【问题标题】：React-native Redux Should business logic be inside actions or reducersReact-native Redux 业务逻辑应该在 action 还是 reducer 中
【发布时间】：2017-07-18 07:33:19
【问题描述】：

我已经开始研究 reactnative - redux 项目。我对这种功能范式完全陌生。我的问题很简单：我有不同的登录/注册选项，其中之一是 facebook。在我的操作文件中，我从 facebook 获取令牌。我应该将它发送到服务器进行检查。这个请求可以返回多个结果

此用户是新用户，打开新用户页面
此用户已存在并已获批准，请打开申请页面
此用户已存在但尚未批准短信验证，请打开短信验证屏幕。

问题是；我应该把这些逻辑放在哪里？我应该在操作上完成所有操作还是只是将事件发送到减速器并让它决定。我对此感到困惑。

谢谢

【问题讨论】：

标签： react-native redux react-redux reducers

【解决方案1】：

根据Redux FAQ entry on "where should my business logic live?"：

对于 reducer 或 action creator 中应该包含哪些逻辑，没有一个明确的答案。一些开发人员更喜欢拥有“胖”的动作创建者，而“瘦”的减速器只是简单地将数据放入动作中并盲目地将其合并到相应的状态中。其他人则试图强调让动作尽可能小，并尽量减少在动作创建者中使用 getState()。（对于这个问题，其他异步方法，如 sagas 和 observables 属于“动作创建者”类别。）

这条评论很好地总结了二分法：

现在，问题是在 action creator 中放入什么，在 reducer 中放入什么，在胖和瘦动作对象之间进行选择。如果你把所有的逻辑都放在动作创建器中，你最终会得到基本上声明状态更新的胖动作对象。 Reducers 变得纯粹、愚蠢、添加这个、删除那个、更新这些功能。他们将很容易组成。但是你的业务逻辑并不多。如果你在 reducer 中加入更多逻辑，你最终会得到漂亮、精简的 action 对象，大部分数据逻辑都在一个地方，但是你的 reducer 更难组合，因为你可能需要来自其他分支的信息。您最终会得到大型化简器或从该州更高层获取额外参数的化简器。

我还在我的博文The Tao of Redux, Part 2 - Practice and Philosophy 中讨论了“厚”和“薄”减速器的概念。

【讨论】：

当然没有像往常一样明确的答案，但我应该选择减脂行动还是减脂？但是，您的博客对我有很大帮助，尤其是在 redux-logic 方面，这将帮助我减少操作的大小以及使用切片缩减器的选择器功能。谢谢