我最近在@ngrx / store学习Angular 6，而其中一个教程是使用@ngrx / store进行状态管理， however I don't understand the benefit of using @ngrx/store behind the scene.
例如，对于简单的登录和注册操作， previously by using the service(Let's call it AuthService) 我们可能会使用它来调用后端api，在AuthService中存储"userInfo"或"token"，将用户重定向到"HOME"页面，我们可以在需要获取userInfo的任何组件中注入AuthService通过使用DI， which simply that one file AuthService handles everything .
现在，如果我们使用@ngrx / store，我们需要定义 Action/State/Reducer/Effects/Selector ，它可能需要写入4或5个文件来处理上述操作或事件，然后有时我们仍然需要使用service来调用backend api， which seems much much more complicated and redundant...
在其他一些场景中，我甚至看到一些页面使用@ngrx / store存储对象或对象列表，如网格数据 . ， is that for some kind of in-memory store usage?
所以回到这个问题， why are we using @ngrx/store over service registration store here in Angular project? 我知道这是用于“ STATE MANAGEMENT ”的用法， but what exactly is the "STATE MANAGEMENT"? Is that something like transaction log and When do we need it? Why would we manage it on the front end? 请随时在@ngrx / store区域分享您的建议或经验！
1 回答
我想你应该阅读关于Ngrx商店的那两篇帖子：
Angular Service Layers: Redux, RxJs and Ngrx Store - When to Use a Store And Why?
Ngrx Store - An Architecture Guide
如果第一个解释了Ngrx Store解决的主要问题，它还引用了React How-To中的这个声明“这似乎同样适用于原始的Flux，Redux，Ngrx Store或任何商店解决方案”：
对我来说，Ngrx商店解决了多个问题 . 例如，当您必须处理可观察对象以及在不同组件之间共享某些可观察数据的责任时 . 在这种情况下，存储操作和缩减器确保始终以“正确的方式”执行数据修改 .
它还为http请求缓存提供了可靠的解决方案 . 您将能够存储请求及其响应，以便您可以验证您所做的请求尚未存储响应 .
第二篇文章是关于是什么让这些解决方案在Facebook的未读消息计数器问题出现在React世界中 .
关于在服务中存储不可验证数据的解决方案 . 当您处理常量数据时，它可以正常工作 . 但是，当几个组件必须更新此数据时，您可能会遇到更改检测问题和不正确的更新问题，您可以使用以下方法解决：
观察者模式与私人主体公共观察和下一个功能
Ngrx商店