Angular 6-为什么使用@ ngrx / store而不是服务注入

我最近正在使用@ ngrx / store学习Angular 6，而本教程之一是使用@ ngrx / store进行状态管理，但是我不了解在后台使用@ ngrx / store的好处。

例如，对于一个简单的登录和注册操作，以前通过使用服务（我们将其称为AuthService），我们可能会使用它来调用后端api，在AuthService中存储“ userInfo”或“ token”，将用户重定向到“ HOME”页面，然后我们可以使用DI将AuthService注入到需要获取userInfo的任何组件中，这只需一个文件AuthService就可以处理所有内容。

现在，如果我们使用@ ngrx / store，我们需要定义Action / State / Reducer / Effects / Selector，可能需要写入4或5个文件来处理上述操作或事件，然后有时我们仍然需要调用后端api使用服务，这似乎更加复杂和多余。

在其他情况下，我什至看到某些页面使用@ ngrx / store存储对象或对象列表（如网格数据）。，这是否适合某种内存存储方式？

回到问题所在，为什么我们在Angular项目中的服务注册存储中使用@ ngrx / store？ 我知道这是用于“状态管理”的，但是“状态管理”到底是什么？那是事务日志之类的东西，什么时候需要？我们为什么要在前端进行管理？请随时在@ ngrx / store区域分享您的建议或经验！

我认为您应该阅读有关Ngrx存储的这两篇文章：

• Angular服务层：Redux，RxJs和Ngrx存储-何时使用存储，为什么？
• Ngrx Store-体系结构指南

如果第一个解释了Ngrx Store解决的主要问题，它还引用了React How-To的这一声明“似乎同样适用于原始的Flux，Redux，Ngrx Store或一般的任何商店解决方案”：

您会知道何时需要助焊剂。如果不确定是否需要它，则不需要它。

对我来说，Ngrx商店解决了多个问题。例如，当您必须处理可观察对象时，以及某些可观察数据的责任在不同组件之间共享时。在这种情况下，存储操作和减速器可确保始终以“正确的方式”执行数据修改。

它还为http请求缓存提供了可靠的解决方案。您将能够存储请求及其响应，以便可以验证所发出的请求尚未存储响应。

第二篇文章是关于如何通过Facebook的未读消息计数器问题使此类解决方案出现在React世界中的。

关于在服务中存储不可观察数据的解决方案。当您处理常量数据时，它可以正常工作。但是，当几个组件必须更新此数据时，您可能会遇到变更检测问题和不适当的更新问题，可以通过以下方法解决：

• 具有私有主题public可观察和下一个功能的观察者模式
• Ngrx商店

还有第三个选项，例如，在服务中包含数据并直接在html中使用service *ngFor="let item of userService.users"。因此，当userService.users在HTML中自动呈现添加或更新操作后在服务中进行更新时，无需任何可观察对象或事件或存储。

如果您的应用程序中的数据用于多个组件，则需要某种服务来共享数据。有很多方法可以做到这一点。

一个中等复杂的应用程序最终将看起来像前端后端结构，其中数据处理在服务中完成，并通过可观察对象将数据公开给组件。

有时，您将需要为数据服务编写某种api，如何获取和获取数据，查询等。许多规则，例如数据的不变性，以及定义良好的修改数据的单个路径。与服务器后端没有什么不同，但是比api调用要快得多且响应更快。

您的api最终看起来像已经存在的许多状态管理库之一。它们的存在是为了解决难题。如果您的应用程序很简单，则可能不需要它们。