我正在开发一个 React + redux + Immutable.js + reselect 应用程序。我正在考虑一种设计，我在化简器和sagas中使用不可变.js但不想将此库与智能组件耦合，因此我的应用程序表示部分尽可能干净。
根据 redux 文档，您的选择器应始终返回不可变对象。
我的想法是在重新选择器中计算派生状态并返回普通 JS 对象。如果我使用记忆选择器，如果 redux 状态的底层部分相同，则不会在每次调用时创建新对象，因此除非需要，否则我的组件不会重新渲染。
我知道我会为可组合性支付部分费用，因为选择器不能用作其他不可变.js就绪选择器的输入，但我会得到更干净的智能组件。
这种解决方案还有其他缺点吗？
为什么 redux 文档如此强烈地鼓励将不可变对象推送到智能组件？
这种解决方案还有其他缺点吗？
toJS即使记住了，也是一项昂贵的操作。争论是，如果您不必这样做，为什么要toJS？
为什么 redux 文档如此强烈地鼓励将不可变对象推送到智能组件？
上述内容，加上它使对整个 redux 管道的推理变得更容易，即任何要陈述的突变(副作用/态射(都更容易绕开一个人的头脑，因为有一个清晰的流程和变化发生点。
综上所述，它归结为偏好以及人们觉得架构中的瓶颈/权衡在哪里。如果您觉得在选择器中具有toJS的干净分离超过了潜在的风险/警告，那么这就是您的架构的正确要求。
关于选择器中可组合性丢失的旁注，您始终可以有两个选择器，一个返回不可变状态 - 用于选择器组合，另一个使用不可变状态选择器并在适当的情况下调用toJS。
这种解决方案还有其他缺点吗？
toJS成本很高，而且调试应用程序也变得更加复杂。
为什么 redux 文档如此强烈地鼓励将不可变对象推送到智能组件？
-
不可变对象的验证比普通对象更深入。在验证的情况下
oldObject === newObject普通对象将在全局级别进行比较，而oldImmutableObject === newImmutableObject对象将进行更深入的比较。这在渲染树上更有效，避免了渲染 React 组件的不必要更新。 -
使用帮助程序函数轻松修改对象。
get，set等等。 -
避免了不必要的数据复制。