当我们将 redux store 传递给 prop 并将该 prop 设置为再次响应状态时，我们不是在重复吗？答案

【问题标题】：Aren't we duplicating when we pass a redux store to prop and setting that prop to react state again?当我们将 redux store 传递给 prop 并将该 prop 设置为再次响应状态时，我们不是在重复吗？
【发布时间】：2018-06-09 04:26:36
【问题描述】：

这是每个 REACT 开发人员最常做的事情......我们使用 redux store 来维护应用程序模型，如果我们想使用 store 信息，我们必须使用订阅（connect() 方法）创建一个属性对象 where mapStateToProps创建存储对象的克隆只读版本以响应 PROP。这还没有结束，因为可访问属性是只读的，我们继续使用 setState() 创建另一个实例来响应同一对象的状态（使其可写），setState() 是同一对象的另一个克隆版本。我们最终创建了同一个对象的多个版本，奇怪的是我们可以继续改变这三个对象中的任何一个，而另一个不知道这可能是一个真正的破坏......有什么办法可以防止这种情况发生吗？ ...如果是这样，它肯定有助于性能并防止克隆对象的恶作剧。

【问题讨论】：

嗯......你不应该把道具变成状态。您应该使用 mapDispatchToProps 从您的反应元素调度操作，这将更新商店，然后这些更改将作为道具传播回来。
如上所述，生成的道具不是只读的，每次我想更改比创建状态更昂贵的对象时，我都可以调度......即使我这样做了，我还没有结束如果要更改该道具内部对象，请创建多个减速器操作？
很抱歉，我很难理解你的措辞。

标签： javascript reactjs redux react-redux state

【解决方案1】：

在 react 中，props 和 state 不应该混淆。如果管理得当，它不会导致任何混淆问题，但是在克隆 props 时没有使用来说明我们是否可以在渲染时使用相同的 props 值。所以是的，没有必要将 props 复制到 state，因为两者的变化都会触发重新渲染。

【讨论】：

【解决方案2】：

setState 方法用于改变局部状态，而 redux（使用动作和 reducer）用于改变全局状态。通常，正如您所说，有一种情况要存储它们，以便我们保持两种状态同步。但是两者都不指向同一个对象，并且创建的本地状态是不可写的。它也是不可变的。

就 redux 状态（全局）而言，它们仅使用操作和 reducer 进行更改。直接改变任何状态是一种反模式反应。 redux 状态只能被读取，不能被改变。本地状态也不应该直接改变。它应该只使用 setState 方法来改变

现在对于您的问题，如果 redux 状态作为 prop 传递，那么 redux 状态的更改将自动重新渲染组件。但是开发人员通常会将 redux 状态克隆（不同的对象）到本地状态，因为本地状态的重新渲染速度很快，但是对本地状态所做的更改不会自动复制到 redux 状态。

【讨论】：

But devs usually make a clone (different object) of the redux state to local state, since re-rendering is fast for local state。那是完全错误的，在道具更改后再次设置状态将启动另一轮不必要的重新渲染。如果你想在 prop 改变时改变你的 dom，你应该使用 props 本身作为 dom 的数据。
如果我在 componentWillReceiveProps 等生命周期方法中设置本地状态，它不会重新渲染。在这种情况下，重新渲染将只有一次。仅供参考，react 的最新更新添加了一个生命周期方法 getderivedstatefromprops 这简化了我正在谈论的过程