在angular 2中使用store(ngrx)有什么好处 [英] What are benefits of using store (ngrx) in angular 2
问题描述
我正在研究角度1.x.x 项目，并考虑将代码升级到角度2 .
I'm working on a angular 1.x.x project and thinking about upgrading my code to angular 2.
现在在我的项目中，我有很多服务(工厂)来处理数据，这些服务几乎将数据保存在 js 数组中(包括缓存和存储)，并通过使用下划线处理数组来处理这些数据.
Now in my project I have many services(factory) for handling data which almost keep data in js arrays(both cache and storage) and process these data by using underscore for handling arrays.
我发现使用ngrx在angular2中有很多示例.
I found that many examples in angular2 using ngrx.
使用商店比较与使用数据服务来处理数据有什么好处?
如果我有多种数据类型(库存，订单，客户...)，我的应用是否需要多个商店?
我如何构造(设计)我的应用程序以处理诸如此类的多种数据类型?
推荐答案
即使您的问题主要基于观点，我也可以为您提供一些想法，为什么ngrx是一个不错的选择.尽管有人说将所有应用程序状态都放在一个对象(单个状态树)中不是一个好主意.但是，我认为您的状态将始终存在.有了商店，它就可以一次全部发现，并且可以明确地跟踪并跟踪变体，而不是在整个过程中乱抛垃圾，并通过组件在本地进行维护.此外，您可以从应用程序中的商店中选择特定属性，因此您只能选择所需的数据.如果然后通过总是返回一个数组并使用Observables来包含化简器中的不变性，则可以使用ChangeDetectionStrategy OnPush. OnPush给您一个不错的性能提升.让我们看一下下图来自官方Angular docs :
Even though your question is primarily opinion-based, I can give you some ideas why ngrx is a good choice. Despite people saying that it's not a good idea to have all of your application state in one single object (Single State Tree). However, in my opinion your state will be there regardless. With a store it's just all in once spot and mutations are explicit and tracked vs littered throughout and maintained locally by components. Additionally, you select specific properties from your store within your application, so you can only select data that you care about. If you then embrace immutability in your reducers by always returning a array for instance and use Observables, you can make use of the ChangeDetectionStrategy OnPush. OnPush gives you a nice performance boost. Let's take a look at the following figure taken from the official Angular docs:
如您所见，Angular App是使用组件体系结构构建的，从而产生了一个组件树.组件上的OnPush表示仅当输入属性发生更改时，更改检测才会生效.例如，如果Child B是OnPush并且Child A是Default并且您在Child A，Child B内部进行更改，则Child A将具有默认的更改检测器，因此将重新呈现.
As you can see, an Angular App is built using a component architecture, which results in a component tree. OnPush on a component means that only if input attributes change, the change detection will kick in. For example if Child B is OnPush and Child A is Default and you change something inside Child A, Child B's change detector won't be triggered since no input attributes have changed. However, if you change something inside Child B, Child A will be re-rendered since it has the default change detector.
关于性能和单一状态树的很多内容.存储的另一个优点是，您实际上可以推理代码和状态更改.因此，大多数Angular 1.x应用程序的实际情况是范围汤.这是Lukas Ruebbelke的博客文章中的精美图片:
So much about performance and the single state tree. Another advantage about the store is that you can actually reason about your code and state changes. So the reality of most Angular 1.x apps is scope soup. Here is a nice graphic from a blog post by Lukas Ruebbelke:
图片显示效果非常好.另一文章来自Tero Parviainen的文章讨论了他如何通过禁止ng-controller来改进Angular应用程序.所有这些都与范围汤有关，并且管理不断变化的状态是困难的. redux动机表示以下参见此处:
The picture demonstrates it pretty good. Another article from Tero Parviainen talks about how he improved his Angular apps by banning ng-controller. That all relates to the scope soup and managing ever-changing state is a difficult. The redux motivation says the following see here:
如果一个模型可以更新另一个模型，则视图可以更新一个模型， 这会更新另一个模型，这反过来可能会导致另一个 查看更新.在某些时候，您不再了解会发生什么 在您的应用中，因为您无法控制何时，为何以及如何控制 它的状态.当系统不透明且不确定时，很难 重现错误或添加新功能.
If a model can update another model, then a view can update a model, which updates another model, and this, in turn, might cause another view to update. At some point, you no longer understand what happens in your app as you have lost control over the when, why, and how of its state. When a system is opaque and non-deterministic, it’s hard to reproduce bugs or add new features.
通过使用ngrx/store，您实际上可以解决此问题，因为您将在应用程序中获得清晰的数据流.
By using ngrx/store you can actually get around this problem because you'll get a clear data flow in your app.
由于ngrx受到redux的极大启发，所以我说同样的主要原则适用:
Since ngrx is highly inspired by redux, I would say that the same main principles apply:
- 真理的唯一来源
- 状态为只读
- 使用纯函数进行更改
因此，在我看来，最大的好处是您可以轻松跟踪用户交互和状态更改的原因，因为您可以调度动作，并且这些动作总是指向一个地点，而对于普通模型，则必须查找所有引用并查看其中的内容.更改内容和时间.
So, in my opinion the biggest benefit is that you are able to easily track user interaction and reason about state changes because you dispatch actions and those lead always to one spot whereas with plain models you have to find all refernces and see what changes what and when.
使用ngrx/store还可以使您使用 devtools 来调试状态容器并还原更改.我想时间旅行是造成redux的主要原因之一，如果您使用的是普通的旧模型，这将非常困难.
Using ngrx/store also enables you to use devtools to see debug your state container and revert changes. Time travelling, I guess, was one of the main reasons for redux and that is pretty hard if you are using plain old models.
已经提到了@muetzerich的可测试性，这也是使用ngrx/store的好处. Reducer是纯函数，这些函数易于测试，因为它们接受输入并仅返回输出，并且不依赖于函数外部的属性，并且没有副作用，例如http通话等.
Testability as @muetzerich mentioned already is also a benefit of using ngrx/store. Reducers are pure functions and those functions are easy to test, because they take an input and simply return an output and do not depend on properties outside the function and have no side-effects, e.g. http calls etc.
要跳到底线，我想说不需要使用ngrx/store来做任何这些事情，但是您将受到限制(上面提到的三个原则)，这些限制提供了一种通用的模式和带来很多好处.
To jump to the bottom line, I would say that don't need to use ngrx/store to do any of these things, but you will be tied to restrictions (the three principles mentioned above) which provide a common pattern and bring nice benefits.
对您的问题:
如果我有多种数据类型(库存，订单，客户...)，我的应用是否需要多个商店?
不，我不建议使用多个商店.
No, I would not suggest to use multiple stores.
我如何构造(设计)我的应用程序以处理诸如此类的多种数据类型?
也许Tero Parviainen的博客文章可以帮助您弄清楚如何设计您的商店.他解释了如何为示例应用程序设计应用程序状态树.
Maybe this blog post by Tero Parviainen helps you to to figure out how to design your store. He explains how to design the application state tree for an example app.
这篇关于在angular 2中使用store(ngrx)有什么好处的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
