Immutable.js 用过吗，真的很好？

#1

Immutable.js

使用不可变数据类型的头一条理由肯定是能够保证做项目的人不能违反不可变原则。 严格地说，Immutable.js 库有助于简化开发过程，因为大家不再需要在代码中追踪数据，寻找数据变更的位置。不可变数据类型取而代之，能始终精确表现当前存储对象(store)中存储的程序状态。

有了这种库，就能发挥上述不可变数据类型的优点，但缺点也确实存在

不便与调试

如果要查看数据直接使用 console.log 需要翻来覆去的深层次的找，如果使用 toJS() 它自带的转换则一定层度上减缓开发速度。
javascript 语法错误就不存在了，若 a.b.w.d ‘w’ 对象名称写错了，现在得到的只会是一个 undefined 而真正的问题无法得知。

不便与迁移

1.toJS() 可以把Immutable对象转换成普通对象，不难免的会在代码中用到(例如与服务器交互)，但如果该对象较为深，则性能消耗的代价也是巨大的，PC 端这一点可以忽略，但移动端则需要考虑，包括 fromJS

不符合主流ES6原生代码的格式

比如 ES6 的解构，就变成了只能使用 get() 或 getIn()，若 props 携带有一定数量，则会带来更多的冗长代码，ES6 的 … 扩展语法也是

压缩后的 Immutable.js 大约 57kb

配合redux的话，中间必用来做转换的 redux-Immutable 引入了整个 Immutablejs 库 无法做 Tree shaking 代码缩减优化

侵入性强

例如引用第三方组件的时候，不得不进行数据转换

入手不易

需要对 Immutable.js 一套 api 进行熟悉才可上手

这是我总结的一些缺点，最终发现 缺点大过了缺点，最后想问一个问题，现在移动端项目盛行，若对于移动端项目而言，Immutable.js 是否真的合适？如果只是为了 不可变 约束，immutability-helper 这类更加更加贴近原生的库是不是要更合适一些

#2

Immutable.js对于移动端感觉过大了，可以看看seamless-immutable，这个是缩小版的Immutable.js，比较适合移动端。

#3

immutablejs 显然不是一套完美的解决方案.

但是从代码的角度来说, 如果更在意程序本身的正确性和可靠性, 对于 Virtual DOM 应用了说, 使用 immutable data 作为基础进行抽象, 才能说是更准确的更可靠的, 因为你要保证了所有代码都无状态而且通过引用对比来判断是否发生改变, 才能在整个应用级别用高度一致的代码来编写和优化.

站在 ClojureScript 的立场来说, immutablejs 不好那是 JavaScript 语言设计本身存在的不足. 当然你如果觉得 JavaScript 是对的, 那 immutablejs 的问题也就是实实在在的不足了.

#4

嗯，我不是否定 Immutable.js 是个很好的库，和同期发布的 React 一样它也很让人称赞的！只是在选型方面，我对它的看法吧，可用来参考它对实际运用的适用程度