反应：Immutable.js 与 JSON.parse(JSON.stringify())答案

【问题标题】：React: Immutable.js vs JSON.parse(JSON.stringify())反应：Immutable.js 与 JSON.parse(JSON.stringify())
【发布时间】：2017-06-14 14:35:23
【问题描述】：

目前我遇到了React 'shouldComponentUpdate' 方法的问题 - 我注意到我通过链接将参数传递给该函数。因此，我无法使用任何优化，因为我将 nextProps 和 this.props 用作相同的东西。

我的问题是 - 我应该如何与我的同事争论以说服他使用不可变数据结构来传递而不是仅使用 JSON.parse(JSON.stringify) 复制对象？是否有任何基准可以比较这种解决问题的方法？

【问题讨论】：

hmmm React 文档对你的同事来说还不够有说服力吗？！！老实说，我希望有人用“复制太多”来抱怨不可变数据，但是如果您的同事已经做了太多JSON.parse(JSON.stringify) 那么他/她的抱怨是什么？
@niceman 您能否指出反应文档中说使用Immutable 是解决此问题的首选方法，而不是使用扩展字符、Object.assign 或 JSON.parse(JSON.stringify() )?这会很有帮助。
官方教程中有：facebook.github.io/react/tutorial/…
通过字符串化然后解析来复制对象甚至没有意义；尽管我没有进行基准测试，但这肯定比做深拷贝要慢。为什么不只在 jsperf 或类似工具上进行基准测试？
这个问题的答案取决于应用程序的具体情况和相当多的意见。如果您的应用程序状态像 10-20 个布尔标志，则传播操作将非常完美。另一方面，如果你在其中有深度嵌套的（比如类似图形的）结构，并且带有循环引用，stringify/parse 就会失败。

标签： javascript json reactjs immutable.js stringify

【解决方案1】：

似乎 stringify/parse 在 Chrome 中比其他更快，而 Immutable.js 最慢 (JSPerf)。我对这个结果感到沮丧，但我找到了this topic on Reddit，最后我明白了不可变绝对不是关于速度，而是关于健壮的 API，再加上 Redux，它真的很闪耀。我也应该从尖锐的 Reddit 讨论中强调这个想法：

别忘了这是 JavaScript，每个浏览器都有多个层优化——意味着今天的快或慢可能是明天慢或快（在合理范围内）

【讨论】：