React-native Redux业务逻辑应该在action或reducers中

时间:2017-07-18 07:33:20

标签: react-native redux react-redux reducers

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

  • 此用户是新的,打开新用户页面
  • 此用户已存在且已获批准,已打开应用程序页面
  • 此用户已存在,但尚未批准短信验证,请打开短信验证屏幕。

问题是;我应该把这些逻辑放在哪里?我应该在动作上完成所有操作,还是只将事件发送到reducer并让它决定。我很困惑。

由于

1 个答案:

答案 0 :(得分:0)

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

  

对于减速器或动作创建者应该采用哪些逻辑,没有一个明确的答案。一些开发人员更喜欢拥有“胖”动作创建器,其中“瘦”缩减器只是简单地将动作中的数据接收并盲目地将其合并到相应的状态中。其他人试图强调保持尽可能小的动作,并最小化动作创建者中getState()的使用。 (出于这个问题的目的,其他异步方法,如sagas和observables属于“行动创造者”类别。)

     

这个评论很好地总结了二分法:

     
    

现在,问题是在动作创建器中放置什么,以及在reducer中,fat和thin动作对象之间的选择。如果将所有逻辑放在动作创建器中,最终会生成基本上声明状态更新的胖动作对象。 Reducers变得纯粹,愚蠢,添加 - 删除它,更新这些功能。它们很容易构成。但是你的业务逻辑并不多。如果你在reducer中加入了更多的逻辑,你最终会得到漂亮的瘦动作对象,大部分数据逻辑都集中在一个地方,但是你的reducer更难以编写,因为你可能需要来自其他分支的信息。你最终会得到大型减速器或减速器,这些减速器或减速器会从该州的较高位置获得额外的参数。

  

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