使用 Immutable.js 从 memoized 选择器返回纯 JS 对象答案

【问题标题】：Returning plain JS object from memoized selector using Immutable.js使用 Immutable.js 从 memoized 选择器返回纯 JS 对象
【发布时间】：2018-10-21 05:33:42
【问题描述】：

我正在开发一个 React + redux + Immutable.js + reselect 应用程序。我正在考虑一种设计，我在 reducers 和 sagas 中使用 Immutable.js，但不想将此库与智能组件耦合，因此我的应用程序的演示部分尽可能干净。

根据redux文档your selectors should always return Immutable object。

我的想法是在重新选择选择器中计算派生状态并返回纯 JS 对象。如果我使用 memoized 选择器，如果 redux 状态的底层部分相同，则不会在每次调用时创建新对象，因此除非需要，否则不会重新渲染我的组件。

我知道我会为可组合性付出部分代价，因为选择器不能用作其他 Immutable.js-ready 选择器的输入，但我会得到更干净的智能组件。

这种解决方案还有其他缺点吗？

为什么 redux 文档如此强烈地鼓励将不可变对象推送到智能组件？

【问题讨论】：

标签： javascript reactjs redux immutable.js reselect

【解决方案1】：

这种解决方案还有其他缺点吗？

toJS 很昂贵，而且调试应用程序也变得更加复杂。

为什么 redux 文档强烈鼓励将不可变对象推送到智能组件？

不可变对象的验证比普通对象更深入。在oldObject === newObject 验证的情况下，普通对象将在全局级别上进行比较，而oldImmutableObject === newImmutableObject 则进行更深入的比较。这在渲染树上更有效，避免了渲染 React 组件的不必要更新。
使用辅助函数轻松修改对象。 get、set 等等。
避免了不必要的数据复制。

【讨论】：

【解决方案2】：

这种解决方案还有其他缺点吗？

toJS 是一个昂贵的操作，即使被记忆。争论是为什么toJS如果你不需要？

为什么 redux 文档强烈鼓励将不可变对象推送到智能组件？

前面提到的，再加上它使整个 redux 管道的推理更容易，即状态的任何突变（副作用/态射）都更容易理解，因为有一个清晰的流程和发生变化的点。

话虽如此，它归结为偏好以及人们感觉到自己架构中的瓶颈/权衡的地方。如果您觉得在选择器中使用 toJS 时，干净的分离比潜在的风险/注意事项更重要，那么这就是对您的架构的正确调用。

关于选择器中的可组合性损失的附带说明，您始终可以有两个选择器，一个返回不可变状态 - 用于选择器组合，另一个使用不可变状态选择器并调用 toJS，其中合适。

【讨论】：