为什么我不应该在 React Redux 中使用 toJS()？ (mapStateToProps)答案

【问题标题】：Why I shouldn't use toJS() in React Redux? (mapStateToProps)为什么我不应该在 React Redux 中使用 toJS()？ (mapStateToProps)
【发布时间】：2018-05-21 11:50:41
【问题描述】：

我刚刚在 Redux 的文档上阅读了它，我不应该真正将 Immutable 与 Redux 一起使用。我就是想不通这件事。为什么我不应该在 mapStateToProps 中使用 toJS()？我的意思是 React 正在使用 Deep Compare，而且我还没有遇到任何重新渲染问题。（我只是登录渲染看看是否有任何泄漏。）

【问题讨论】：

相关stackoverflow.com/questions/53186890/…

标签： javascript reactjs redux react-redux immutable.js

【解决方案1】：

为什么我不应该在 mapStateToProps 中使用 toJS()

您不应该在mapStateToProps 中使用toJS()，因为toJS() 返回一个新的对象引用，即使connect 是纯的（即它进行浅比较），它也可能会返回一个false negative 当对象嵌套时，在这种情况下，您的组件将重新渲染，即 render 函数将被调用，并且 react 必须运行差异算法，这将对性能产生影响你的应用程序去了。

【讨论】：

嗯，但是为什么当 React 进行深度比较时它会重新渲染，所以如果值本身相同，它就不会重新渲染？
我确定我遗漏了一些东西。：/我的意思是ofc，ref会改变，但值本身不会改变，但很明显，所以我确定我错过了一些重要的东西，并且看不到全貌。（如果你能给我一个例子，那将是一个巨大的帮助：D）
这并不是说仅仅重新渲染会增加性能，说对象有两层嵌套，在 PureComponent 中进行浅比较时，会比较对象引用，因此它会返回 false。现在，组件的 render() 函数被调用，在这里 react 比较前一个和当前的 DOM 并决定在哪里渲染或不渲染。现在这个计算量很大，需要做这个计算的次数越多，性能损失就越大
我明白了，这完全有道理。从现在开始，我将尽量避免将 ImmutableJS 与 Redux 一起使用。谢了哥们！ :)
@IstvanOrban，不，你错了，你应该避免在 mapStateToProps 中使用 toJS 方法，你应该更喜欢使用 ImmutableJS，因为为了知道值是否改变，你只需要检查参考，因此比较要快得多。