即使我们可以用服务做所有事情，为什么我们还需要 NgRX？ [已关闭]

Question

我参与过一些 Angular 2+ 项目，但我仍然想知道为什么我们需要 NgRX。 我可以用服务来实现一切，而且它们似乎更容易理解。 我不确定这是否是因为我对 NgRX 不熟悉，但无论如何我找不到 NgRX 的特定用例。 谁能给我一些关于以下内容的解释？

• NgRx 和服务的状态实现之间的差异
• 每种实施方式的优缺点
• 实施NgRX时我们需要考虑什么？
• 对性能有任何疑问吗？

Answer 1

这将是一篇相当

ngrx

专业的帖子，因为我已经使用它近三年了。我见过很多次它脱离了框架，管理

ngrx

状态变得很痛苦，但主要是由于忽视应用程序架构和最佳实践。如果应用得当，编写和审查

ngrx

代码是一种乐趣，因为事物具有严格的结构。

恕我直言：它可以在任何应用程序中使用，它在更大的应用程序中确实有意义。

ngrx

可以为您做的所有事情也可以使用服务来构建，但从长远来看，这将变得越来越困难。当您意识到自己需要它时，就为时已晚了。

这是一篇讨论这一切的文章。

https://blog.strongbrew.io/do-we-really-need-redux/

NgRx 和服务的状态实现之间的区别

虽然

ngrx

对于如何读取/更新/写入数据有相当多的看法，但服务将更多的事情留给了开发人员。我倾向于选择 CRUD 操作以保证一致性。

• Angular 服务通常公开

  Observables

  ，其中保存数据和更新所述

  Observables

  中的数据的函数。通常这意味着我们最终会在每个服务中重新创建 CRUD 操作。

• ngrx

  将数据公开为

  selectors

  ，并将更新/删除功能作为

  actions

  。除此之外，还有

  effects

  来处理异步操作。读取和写入之间有明显的区别，因为逻辑发生在不同的地方，而不是服务类，后者大多都是一体的。
• Angular 服务使得在某些类中构建私有状态管理变得非常容易，这通常是不鼓励的。

每种实施方式的优缺点

有一些东西使得

ngrx

有价值，例如它的扩展，但需要正确使用和配置它们。对我来说，主要价值是它提供的一致性。

• 开发工具让您更容易了解哪些值更新的时间和频率。使用控制台日志进行调试很痛苦：
  • https://ngrx.io/guide/store-devtools
• 有一个

  @ngrx/entity

  包使管理集合变得更加容易，因为它提供了

  upsertOne

  或

  updateMany

  等具有明确定义类型的方法。它还通过生成选择器提供轻松访问：
  • https://ngrx.io/guide/entity

• @ngrx/data

  是

  @ngrx/entity

  包的扩展，通过提供更新/删除实体的 API 方法，无需编写大量服务。
  • https://ngrx.io/guide/data
• 您始终可以使用自己的服务来扩展

  @ngrx/effects

  。

对性能有任何疑问吗？

如果忽视

@ngrx

最佳实践，性能可能会受到影响：

• https://blog.strongbrew.io/Redux-best-practices
• 尽可能保持状态平坦
使用
• ngrx

   创建的 

  createSelector

  选择器会被记忆，这意味着它们只会在状态更改时触发更改。这是

  ngrx

  的性能专家，在大量服务中重新实现它可能需要大量工作
  • https://medium.com/swlh/memoization-with-selectors-in-ngrx-c60e67a08161#:~:text=NgRx%20selectors%20help%20retrieve%20subset,of%20the%20features%20of%20Selectors。

实施NgRX时我们需要考虑什么？

尽快获得正确的最佳实践。