我最近正在使用@ngrx/store学习Angular 6，而其中一个教程是使用@ngrx/store进行状态管理，但是我不明白在幕后使用@ngrx/store的好处。
例如，对于一个简单的登录和注册操作，以前通过使用服务（让我们称之为AuthService），我们可以使用它来调用后端api，在AuthService中存储“userInfo”或“token”，将用户重定向到“HOME”页面，我们可以在任何需要使用DI获取userInfo的组件中注入AuthService，这只是一个文件AuthService处理所有事情。
现在如果我们使用@ngrx/store，我们需要定义Action/State/Reducer/Effects/Selector，可能需要编写4到5个文件来处理上述action或event，那么有时我们仍然需要使用service调用后端api，这似乎要复杂得多，也很多余…
在其他一些场景中，我甚至看到一些页面使用@ngrx/store来存储对象或对象列表，例如网格数据。，这是为了某种内存存储使用吗？
那么回到问题上，为什么我们在Angular项目中使用@ngrx/store over服务注册store？我知道这是为了“STATE MANAGEMENT”的用法，但是“STATE MANAGEMENT”到底是什么？那是类似于事务日志和我们什么时候需要它？为什么我们要在前端管理它？请随时在@ngrx/store区域分享您的建议或经验！
我认为你应该阅读这两篇关于Ngrx商店的文章：
如果第一个解释了Ngrx Store解决的主要问题，它还引用了React How-To中的这句话，“这似乎同样适用于原始Flux、Redux、Ngrx Store或任何一般的商店解决方案”：
你会知道什么时候需要Flux。如果你不确定是否需要它，你就不需要它。
对我来说，Ngrx存储解决了多个问题。例如，当您必须处理可观察对象时，以及当不同组件之间共享某些可观察数据的责任时。在这种情况下，存储操作和还原器可确保始终以“正确的方式”执行数据修改。
它还为超文本传输协议请求缓存提供了可靠的解决方案。您将能够存储请求及其响应，以便您可以验证您正在发出的请求尚未存储响应。
第二篇文章是关于是什么让这些解决方案出现在Facebook的未读消息计数器问题的React世界中。
关于您在服务中存储不可观察数据的解决方案。当您处理常量数据时，它可以正常工作。但是当多个组件必须更新此数据时，您可能会遇到更改检测问题和不正确的更新问题，您可以通过以下方式解决：
