Redux 动作/减速器与直接设置状态 [英] Redux actions/reducers vs. directly setting state

问题描述

我是 Redux 的新手.我无法理解 action 和 reducer 与直接修改 store 的组件的价值.

I'm new to Redux. I'm having trouble understanding the value of actions and reducers vs. components directly modifying the store.

在 Redux 中，您的 React 组件不会直接更改存储.相反，他们调度一个动作——有点像发布消息.然后，reducer 处理操作——有点像消息订阅者——并更改状态(更准确地说，创建一个新状态)作为响应.

In Redux, your React components don't change the store directly. Instead they dispatch an action -- sort of like publishing a message. Then a reducer handles the action -- sort of like a message subscriber -- and changes the state (more precisely, creates a new state) in response.

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

I feel like the pub/sub-like interaction adds layers of indirection that make it harder to understand what a component is actually doing -- why not just allow components to pass new state to the Redux store directly? Would it be a bad thing to inject something like this.props.setReduxState into a React component?

我开始理解为什么状态本身需要不可变的价值(相关问题——Redux 不只是美化了全局状态吗?)，与检查更新以查看需要更新哪些组件 props 以响应状态更改有关.我的问题是额外的 action/reducer 层 vs. 直接操作 store.

I'm starting to understand the value of why the state itself needs to be immutable (related question -- Isn't Redux just glorified global state?), related to checking for updates to see which component props need to be updated in response to state changes. My question is the extra action/reducer layers vs. manipulating the store directly.

推荐答案

当我决定深入 Redux 兔子洞时，我遇到了一些非常相似的问题.就我而言，我只使用 React 内部状态开发相对较小的应用程序和组件，它仍然工作得很好.只有当应用程序和组件数量变得越来越大时，setState 才变得有些笨拙.

I had some very similar questions when I decided on going down the Redux rabbit hole. In my case I was developing relatively small apps and components using just the React internal state, which still works really well. It was only when the app and the number of components grew much larger that setState became somewhat unwieldy.

我认为这一点没有得到足够的强调 - 如果您正在开发一个相对较小的应用程序或一些很容易在没有强大的不可变存储解决方案的情况下易于跟踪的组件，则您不必总是使用 Redux.有很多必要的样板才能开始使用，在某些情况下可能会非常耗时.

I don't think this is emphasized enough - you don't always have to use Redux if you're working on a relatively small app or a few components that are easy enough to keep track of without a robust immutable store solution. There is a lot of necessary boilerplate just to get started, which can be overly time consuming in some instances.

话虽如此，React + Redux 是一个很好的设计范式，一旦您习惯了它并拥有您可以调用的自己的样板，就可以遵循它.Redux 本质上更喜欢 props 而不是 state，这迫使设计不可变，因为你(通常)不能改变 props.这就是让 Redux DevTools 成为时间机器"的原因，以及其他人之前提到的可以扔到商店的所有中间件.

That being said, React + Redux is a great design paradigm to follow once you are used to it and have your own boilerplate you can call upon. Redux essentially favors props over state, which forces immutable design as you (generally) can't mutate props. This is what makes the Redux DevTools "time machine" possible, along with all of the middleware that you can throw at your store as previously mentioned by others.

中间件是其中的重要组成部分，尤其是随着更精确的同步和异步任务解决方案的出现，如 redux-saga (https://redux-saga.js.org/).IMOthunks"(https://github.com/gaearon/redux-thunk)是刚开始时，比 saga 更容易理解，除非您已经是生成器的专家，但 saga 的可预测性要好得多，因此从长远来看是可测试的.

Middleware is a big part of it, especially with the advent of more precise solutions for sync and async tasks alike like redux-saga (https://redux-saga.js.org/). IMO "thunks" (https://github.com/gaearon/redux-thunk) are easier to grok than sagas when you're just getting started, unless you're already an expert with generators, but sagas are much more predictable and therefore testable in the long run.

因此，与其为每个组件设置一个单独的内部状态，不如使用一组动作/reducers 来代替，知道您不能错误地改变状态.我找到了 ImmutableJS 的组合(https://facebook.github.io/immutable-js/)和重新选择(https://github.com/reactjs/reselect)，其中为您提供可组合的选择器 - 对此非常有用.不需要 Object.assigns 或大量的扩展运算符，它为您创建一个新对象.

So instead of having a separate internal state for each component, you can have a set of actions / reducers that you use instead, knowing that you can't mistakenly mutate the state. I've found the combination of ImmutableJS (https://facebook.github.io/immutable-js/) and Reselect (https://github.com/reactjs/reselect), which gives you composable selectors - to be great for this. No need for Object.assigns or tons of spread operators, it creates a new object for you.

我不会急于将现有的非 Redux 项目转换为 Redux，工作流程的不同足以引起严重的混乱，但您很难为尚未拥有的新项目找到样板Redux 在他们的工作流程中.比如React Boilerplate"(https://github.com/react-boilerplate/react-boilerplate)，我知道这种方式一开始让我大吃一惊，但绝对值得一试.它确实测试了您的函数式编程能力.

I wouldn't be in a hurry to convert existing non-Redux projects into Redux, the workflow is different enough to cause significant confusion, but you'd be hard pressed to find boilerplates for new projects that don't already have Redux in their workflow. Such as "React Boilerplate" (https://github.com/react-boilerplate/react-boilerplate), I know this kind of blew my mind at first, but definitely worth getting a feel for. It really tests your functional programming chops.

这篇关于Redux 动作/减速器与直接设置状态的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！