在 Angular 2 中使用 store (ngrx) 有什么好处

尽管你的问题主要是基于意见的，但我可以给你一些 idea ，为什么ngrx是一个好的 Select .尽管人们说将所有应用程序状态放在一个对象(单一状态树)中并不是一个好主意.然而，在我看来，不管怎样，你的州都会在那里.有了一家store ，它只需一次就能发现和跟踪Mutations ，而不是遍及各处，并由组件在本地维护.此外，您可以从应用程序内的存储区 Select 特定属性，因此只能 Select 您关心的数据.如果您随后通过始终返回数组并使用可观察对象来接受减法器中的不变性，则可以使用ChangeDetectionStrategy OnPush.OnPush会给您带来很好的性能提升.让我们来看一下从官方的Angular docs取来的以下数字:

个

如您所见，一个Angular App是使用组件架构构建的，这会生成一个组件树.组件上的OnPush意味着只有当输入属性更改时，更改检测才会生效.例如，如果Child B是OnPush,Child A是Default，并且您更改了Child A内部的某些内容，则Child B的更改检测器不会被触发，因为没有任何输入属性更改.但是，如果您更改了Child B中的某些内容，Child A将重新呈现，因为它具有默认的更改检测器.

关于性能和单一状态树的内容就这么多了.该应用store 的另一个优点是，您可以对代码和状态更改进行推理.所以现实中最有棱角的1.x应用程序是scope soup.以下是卢卡斯·鲁贝尔克(Lukas Ruebbelke)的一张blog post码的精美图片:

这张照片很好地说明了这一点.来自Tero Parviainen的另外article名用户讲述了他如何通过禁止ng-controller款应用程序来改进自己的Angular应用程序.所有这些都与范围和管理不断变化的状态有关，这是一个困难的问题.redux动机说明如下see here:

如果一个模型可以更新另一个模型，则视图可以更新模型， 它更新了另一个模型，而这反过来可能会导致另一个 要更新的视图.在某种程度上，你不再理解发生了什么 在您的应用程序中，因为您已无法控制何时、为什么和如何 它的状态.当一个系统是不透明和不确定的时，很难 复制错误或添加新功能.

通过使用ngrx/store，你实际上可以绕过这个问题，因为你会在应用程序中获得清晰的数据流.

由于ngrx受到redux的高度启发，我想说同样的main principles个应用程序:

• 唯一的真相来源
• 状态为只读
• 更改是使用纯函数进行的

所以，在我看来，最大的好处是，你可以很容易地跟踪用户交互和状态变化的原因，因为你可以调度操作，这些操作总是指向一个点，而在普通模型中，你必须找到所有的引用，并看到什么变化，什么变化，什么时候变化.

使用ngrx/store还可以使用devtools查看调试状态容器和恢复更改.时间旅行，我想，是redux的主要原因之一，如果你使用的是普通的旧模型，这是相当困难的.

@muetzerich已经提到的可测试性也是使用ngrx/store的一个好处.还原器是纯函数，这些函数很容易测试，因为它们接受输入并简单地返回输出，不依赖于函数之外的属性，也没有副作用，例如http调用等.

说到底线，我想说的是，不需要使用ngrx/store来做任何这些事情，但你会受到限制(上面提到的三个原则)，它们提供了一个共同的模式，并带来了很好的好处.

对于您的问题:

Do I need multiple store for my app if I have multiple data type (stock, order, customer...)?

不，我不建议使用多家store .

How can I structure (design) my app to deal with multiple data types like these?

也许Tero Parviainen的这blog post本书可以帮助你了解如何设计你的store .他解释了如何为示例应用程序设计应用程序状态树.