我最近在@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个文件来处理上述动作或事件，然后有时我们还需要调用backend api使用服务，这看起来要复杂多余......
在其他一些场景中，我甚至看到一些页面使用@ngrx / store存储对象或对象列表，如网格数据。是否适用于某种内存存储使用？
回到这个问题，为什么我们在Angular项目中使用@ngrx / store而不是服务注册存储？我知道这是用于“国家管理”的用法，但究竟什么是“国家管理”？这是什么类似事务日志，我们什么时候需要它？我们为什么要在前端管理它？请随时在@ngrx /商店区分享您的建议或经验！
我想你应该阅读关于Ngrx商店的那两篇帖子：
如果第一个解释了Ngrx Store解决的主要问题，它还引用了React How-To中的这个声明“这似乎同样适用于原始的Flux，Redux，Ngrx Store或任何商店解决方案”：
你会知道什么时候需要Flux。如果您不确定是否需要它，则不需要它。
对我来说，Ngrx商店解决了多个问题。例如，当您必须处理可观察对象以及在不同组件之间共享某些可观察数据的责任时。在这种情况下，存储操作和缩减器确保始终以“正确的方式”执行数据修改。
它还为http请求缓存提供了可靠的解决方案。您将能够存储请求及其响应，以便您可以验证您所做的请求尚未存储响应。
第二篇文章是关于是什么让这些解决方案在Facebook的未读消息计数器问题出现在React世界中。
关于在服务中存储不可验证数据的解决方案。当您处理常量数据时，它可以正常工作。但是，当多个组件必须更新此数据时，您可能会遇到更改检测问题和不正确的更新问题，您可以使用以下方法解决：
还有第三种选择，在服务中使用数据并直接在html中使用服务，例如*ngFor="let item of userService.users"。因此，当您在html中自动呈现添加或更新操作后更新服务中的userService.users时，不需要任何observable或事件或存储。