当数据由于双向数据绑定而总是同步时,在Angular中使用NgRx的原因是什么



NgRx,它是React的Redux的Angular版本,用于状态管理。在React中,状态管理可能会变得复杂,Redux会提供帮助。对于Angular,情况不应该如此,因为由于双向数据绑定,所有内容都是同步的。

然而,我看到很多项目使用NgRx。

为什么会这样?

双向绑定和状态管理是完全不同的概念。

考虑这个例子。

假设您有一个web应用程序,您可以在多个位置使用登录用户的名称。不是每次都从服务器查询名称,而是将其放在NgRx存储中并从那里查询。这样可以节省从服务器获取数据的时间和资源。这与双向绑定无关。

这是一个极其简单的例子,不需要NgRx。但让我们发挥我们所拥有的。

我们可以通过注入一个服务和一个可观察的来做到这一点吗。我们当然可以。

但是,除了对后端进行get-rest调用外,您的服务还需要维护状态。考虑到数据也是从多个数据源异步传入的。假设您希望在更新名称时进行一些错误处理。假设更新名称触发多个异步操作,每个操作都有自己的延迟和错误处理。假设多个组件使用状态值。当然,您可以使用服务和可观察性来编写所有这些。最后,您的代码可能看起来与使用Redux类似。

NgRx代表角反应扩展。简而言之,它是一个基于Redux模式的状态管理系统。这将帮助您在更大角度的应用程序中管理应用程序状态。

它将按预期工作,因为所有组件都可以从特定服务中获取或设置所需的数据。但是,实际的问题是如果我们刷新页面,我们将丢失存储在angular服务中的应用程序状态

因此,如果我们使用angular服务来保持应用程序状态,则有必要使用后端来保存应用程序状态。然后,当页面再次重新加载时,我们应该从后端获取状态(持久状态)。

众所周知,状态不仅仅是作为用户数据的数据,它还将决定什么应该在屏幕上可见。对于较小的应用程序,可以使用组件和服务进行应用程序状态管理。但是,当我们的应用程序变得复杂和庞大时,管理应用程序状态将变得困难。

Redux是一种状态管理模式和实现该模式的库模式转换为任何应用程序。

使用Redux管理国家背后的主要理念模式是我们只有一个中央商店来保存所有应用程序状态。

我们可以将此存储视为一个大型javascript对象,它包含我们的应用程序需要不同部分的数据。

我们的组件和服务可以相互通信。但是他们从这个中央商店接收他们的状态。

我们可以说,商店是管理整个应用程序状态。

有关详细信息,请单击此处。

参考编号:https://www.c-sharpcorner.com/article/state-management-in-angular-using-ngrx/

NgRx网站有以下内容:为什么使用NgRx Store进行状态管理?

上面写着:

当您构建一个具有大量用户交互和多个数据源的应用程序时,或者当管理服务中的状态不再足够时,您可能会使用NgRx。

然后它继续这样做:

一个很好的指南,可能有助于回答这个问题,";我需要NgRx商店吗"是SHARI原则:

  • 共享:被许多组件和服务访问的状态
  • 水合状态:从外部储存中持续并重新水合的状态
  • 可用:重新输入路线时需要可用的状态
  • 已检索:必须检索的状态,但有副作用
  • 受影响:受其他来源的操作影响的状态

它还提醒您注意:

然而,意识到使用NgRx Store会带来一些权衡也是至关重要的。它并不意味着是编写代码的最短或最快的方法。它还鼓励使用许多文件。

我将尝试提供一个更简单的解释:

双向数据绑定的问题是,在现实生活中的应用程序中,您通常会得到复杂的多级组件树。

某些组件在某个时刻的存在只是为了从其父母那里获取数据并将其传递给其子女。当你需要更改某些内容或进行一些简单的重构时——例如,移动一个组件或在层次结构中引入一个新组件——为了保持数据绑定的工作,你将需要进行大量不必要的重新布线。即使是简单的重构,也会因为有太多的输入/输出需要修复而放弃。

这根本不是NgRx的问题。

最新更新