为什么即使我们可以用服务做所有事情，我们也需要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 Services通常公开Observables，其中包含数据和用于更新所述Observables中的数据的功能。通常，这意味着我们最终会在每个服务中重新创建CRUD操作。
• ngrx将数据公开为selectors，更新/删除功能为actions。最重要的是，有effects处理异步操作。读写操作之间存在明显的区别，因为逻辑发生在不同的地方，而服务类则大多是多合一的。
• 角度服务使在某些通常不建议使用的类中构建私有状态管理变得非常容易。

每种实现的利弊

有一些使ngrx有价值的东西，例如它的扩展名，但需要正确使用和配置。对我来说，主要的价值就是它的一致性。

• 借助devtools，您可以更轻松地了解何时何地更新了哪些值。使用控制台日志进行调试很麻烦：
  • 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时我们需要考虑什么？

尽快获得最佳实践。