我正在开发 React + redux + Immutable.js + reselect 应用程序。我正在考虑在 reducer 和 sagas 中使用 Immutable.js 的设计，但不想将这个库与智能组件结合起来，所以我的应用程序的展示部分尽可能干净。
根据 redux 文档 your selectors should always return Immutable object .
我的想法是在重新选择选择器中计算派生状态并返回纯 JS 对象。如果我使用 memoized 选择器，如果 redux 状态的底层部分相同，则不会在每次调用时创建新对象，因此除非需要，否则我的组件不会重新呈现。
我知道我会部分支付可组合性，因为选择器不能用作其他 Immutable.js-ready 选择器的输入，但我会得到更简洁的智能组件。
这种解决方案还有其他缺点吗？
为什么 redux 文档如此强烈地鼓励将不可变对象(immutable对象)推送到智能组件？
最佳答案
Are the any other drawbacks of such solution?
toJS 是一项昂贵的操作，即使已内存。争论的焦点是，如果不需要，为什么要使用 toJS？
Why does redux documentation so strongly encourages to push Immutable object to smart components?
前面提到的，再加上它使得对整个 redux 管道的推理变得更容易，即状态的任何突变(副作用/态射)都更容易理解，因为有一个清晰的流程和发生变化的点。
综上所述，归结为偏好以及人们认为架构中的瓶颈/权衡所在。如果您觉得在选择器中使用 toJS 时，干净的分离胜过潜在的风险/注意事项，那么这就是您的架构的正确调用。
关于选择器中可组合性丧失的旁注，您始终可以有两个选择器，一个返回不可变状态——用于选择器组合，另一个使用不可变状态选择器并调用 toJS，在适当的地方。
关于javascript - 使用 Immutable.js 从 memoized 选择器返回纯 JS 对象，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50281493/