时间戳

首页 > 解决方案 > Angular 6 - 为什么使用@ngrx/store 而不是服务注入

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

问题描述

我最近正在使用 @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个文件来处理上述动作或事件，那么有时我们仍然需要调用后端api使用服务，这似乎更加复杂和多余......

在其他一些场景中，我什至看到一些页面使用@ngrx/store 来存储对象或对象列表，例如网格数据。，这是为了某种内存存储使用吗？

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

标签： angular5angular6ngrx-storestate-management

解决方案

我认为您应该阅读有关 Ngrx 商店的两篇文章：

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

你会知道什么时候需要 Flux。如果您不确定是否需要它，则不需要它。

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

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

第二篇文章是关于 Facebook 的未读消息计数器问题导致此类解决方案出现在 React 世界中的原因。

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

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

推荐阅读