带Immutable.js的NGRX

Question

根据对Ngrx用数组存储不可变状态？问题的回答，maxime1992声明他不建议将Immutable.js与ngrx一起使用。

我知道使用Immutable.js与redux一起使用是一种广泛而正常的做法，目的是在存储更改上强制执行不可变性，但是为什么没有人想要在角应用程序上做同样的事情。库应该比扩展操作符更好地处理不可变的数据更改。

那么，将Immutable.js与ngrx结合使用的缺点是什么？

Answer 1

我可以试着提供更多的信息:)

我知道结合使用Immutable.js和redux是一个广泛的和正常的实践。

我想看看这方面的趋势图。我敢打赌，既然ES6的数字没有上升。

几年前，当不变模式开始在前方的世界蔓延时，许多人并不习惯这种模式。因此，Immutable.js很好地隐藏了不变性背后的“复杂性”，并且只以一种非常优化的方式处理众所周知的结构。

另外，当我在一年半前开始了一个巨大的角度项目时，我不得不决定要么使用Immutable.js，要么不使用。我决定去做这件事，因为它的表现似乎令人难以置信。用类型记录生成项目(我很高兴它有！)但几周后，我注意到Immutable.js对打字稿的表现确实不太好(也许在这段时间里，它确实发生了变化，因为我再也没有用过它了)。我更希望有一个类型良好的代码，而不是为我设置一个关于不可变性的库。因此，在开发了2个月之后，我决定进行一个huuuuge并删除不变的JS，主要使用纯JS (map，filter，它们返回新的引用)。

例如，如果您(来自immutablejs网站)：

import Immutable from require('immutable');
var map1: Immutable.Map<string, number>;
map1 = Immutable.Map({a:1, b:2, c:3});
var map2 = map1.set('b', 50);
map1.get('b'); // 2
map2.get('b'); // 50

如果您决定重命名您的商店的一部分，祝您能够找到所有的引用，比如：map1.get('b');。

然而，对于纯JS，您将完全没有问题，如果忘记重命名，类型记录将引发错误。

的确，我的代码库周围有很多扩展对象，即使发现它非常容易读，那也是“样板”。

现在，说到ngrx，他们做了一个很好的库来处理大部分问题，称为@ngrx/实体。

关于香水，我一直在开发两个大型应用程序，这一点没有问题。特别是自createSelector函数发布以来，该函数应用回忆录，避免每次商店发生变化时重新计算所有的选择器。

所以当你说

库应该比扩展操作符更好地处理不可变的数据更改。

我想说你根本不应该担心。真的。自己尝试，创建一个Stackblitz，并尝试用大量的对象编写一个小的测试/基准测试，这些对象都是您一直在添加/更新的。几个月前，我用一组非常大的数组/对象完成了这一任务，这是完全正确的。

总之，最大的问题是类型推理。但在我看来你就是不需要它。如果你害怕错过一些关于不可变的东西，你应该只使用开发模式https://www.npmjs.com/package/ngrx-store-freeze，如果你试图从存储中突变一个对象，它会抛出一个错误。