Redux动作/减速器与直接设置状态

时间:2016-07-09 15:44:06

标签: reactjs redux

我是Redux的新手。我无法理解动作和缩减器与直接修改存储的组件的价值。

在Redux中,您的React组件不会直接更改商店。相反,他们会发送一个动作 - 有点像发布消息。然后,reducer处理动作 - 有点像消息订阅者 - 并更改状态(更准确地说,创建一个新状态)作为响应。

我觉得pub / sub-like交互增加了间接层,使得更难理解组件实际在做什么 - 为什么不让组件直接将新状态传递给Redux存储?将类似this.props.setReduxState的内容注入React组件会不会是一件坏事?

我开始理解为什么状态本身需要不可变的相关问题(相关问题 - Isn't Redux just glorified global state?),与检查更新有关,以查看响应中需要更新哪些组件道具陈述变化。我的问题是额外的动作/减少层与直接操纵商店。

2 个答案:

答案 0 :(得分:2)

在开发过程中,您经常需要知道 如何更改状态。通过发出动作来改变状态允许您保留对这些问题的答案。

操作是指示商店应如何修改的信息的有效负载。此信息以普通javascript对象的形式表示,允许记录,序列化和存储此信息。由于记录了所有历史记录",您可以稍后重放所有操作链以进行调试或测试。与Redux DevTools之类的工具一起,它使开发过程变得非常简单和惊人。由于所有商店修改都会记录到监视器中,因此您可以在每个步骤中看到 时修改状态。更重要的是,您可以通过行动链返回或前进。

将所有突变集中在一个地方的另一个好处是,它更容易控制州。这保证了所有突变都以严格的顺序逐个发生,并且没有回调可以使应用程序行为不稳定。它还允许将某些操作常用的功能保留在一个位置,或者换句话说,应用中间件。

答案 1 :(得分:1)

当我决定走下Redux兔子洞时,我遇到了一些非常相似的问题。就我而言,我只使用React内部状态开发相对较小的应用程序和组件,这仍然很有效。只有当应用程序和组件数量变得更大时,setState变得有点笨拙。

我认为这一点不够强调 - 如果您正在使用相对较小的应用程序或一些容易跟踪的组件而没有强大的不可变存储解决方案,那么您并不总是必须使用Redux 。开始时有很多必要的样板,在某些情况下这可能过于耗时。

话虽这么说,React + Redux是一个伟大的设计范例,一旦你习惯了它,你可以调用它自己的样板。 Redux基本上偏爱状态上的道具,这迫使不可变的设计,因为你(通常)不能改变道具。这就是Redux DevTools“时间机器”成为可能的原因,以及您可以在商店中抛出的所有中间件,如前面提到的那样。

中间件是其中的重要组成部分,特别是随着更精确的同步和异步任务解决方案的出现,如redux-saga(https://redux-saga.js.org/)。当你刚开始时,IMO“thunks”(https://github.com/gaearon/redux-thunk)比sagas更容易理解,除非你已经是发电机的专家,但是从长远来看,sagas更容易预测,因此是可以测试的。 / p>

因此,您不必为每个组件设置单独的内部状态,而是可以使用一组您使用的操作/缩减器,因为您知道不能错误地改变状态。我发现ImmutableJS(https://facebook.github.io/immutable-js/)和Reselect(https://github.com/reactjs/reselect)的组合,它给你可组合的选择器 - 对此很好。不需要Object.assigns或大量的传播运算符,它会为您创建一个新对象。

我不急于将现有的非Redux项目转换为Redux,工作流程不同会导致严重的混乱,但是您很难找到尚未拥有的新项目的样板Redux在他们的工作流程中。比如“React Boilerplate”(https://github.com/react-boilerplate/react-boilerplate),我知道这首先引起了我的注意,但绝对值得一试。它确实测试了你的函数式编程。