既然服务无所不能，为什么还需要 NgRX？
Why do we need NgRX even we can do everything with services?
我从事过一些 Angular 2+ 项目，但我仍然想知道为什么我们确实需要 NgRX。
我可以用服务来实现一切，而且它们似乎更容易理解。
我不确定这是不是因为我不熟悉 NgRX，但无论如何我找不到 NgRX 的特定用例。
谁能给我一些关于以下内容的解释？
- NgRx 和服务的状态实现之间的差异
- 每个实施的优缺点
- 我们在实现 NgRX 时需要考虑什么？
- 对性能有任何顾虑吗？
这将是一个相当 ngrx-pro post 因为我已经使用它近 3 年了。我已经看到很多次它偏离轨道并且管理 ngrx-state 变得很痛苦，但主要是由于忽视了应用程序架构和最佳实践。如果应用得当，编写和审查 ngrx 代码是一种乐趣，因为事物具有严格的结构。
恕我直言：它可以在任何应用程序中使用，在更大的应用程序中确实很有意义。 ngrx 可以为您做的所有事情也可以使用服务来构建，但是从长远来看 运行 会变得越来越难。当你意识到你需要它时，为时已晚。
这是一篇讨论这一切的文章。
https://blog.strongbrew.io/do-we-really-need-redux/
difference between state implementation by NgRx and Services
虽然 ngrx 对如何 read/update/write 数据持有相当多的意见，但服务留给开发人员更多的事情。我倾向于选择 CRUD 操作以保持一致性。
- Angular 服务通常公开
Observables，其中保存数据和功能以更新上述 Observables 中的数据。通常这意味着我们最终会在每个服务中进行 re-creating CRUD 操作。
ngrx 将数据公开为 selectors，update/delete 的功能为 actions。除此之外还有 effects 来处理异步操作。读和写之间有明显的区别，因为逻辑发生在不同的地方，而不是服务 类，后者主要 all-in-one。- Angular 服务使得在某些 类 中构建私有状态管理变得非常容易，这通常是令人沮丧的。
pros and cons of each implementation
有一些东西使 ngrx 有价值，例如它的扩展，但需要正确使用和配置它们。对我来说主要价值是它提供的一致性。
- devtools 可以更容易地了解哪些值更新的时间和频率。使用控制台日志进行调试很痛苦：
- 有一个
@ngrx/entity-package 可以更轻松地管理集合，因为它提供了 upsertOne 或 updateMany 等具有 clearly-defined 类型的方法。它还通过生成选择器提供轻松访问：
@ngrx/data 是 @ngrx/entity 包的扩展，通过向 update/delete... 实体提供 API 方法，无需编写大量服务
- 您可以随时使用自己的服务扩展
@ngrx/effects。
any concerns with performance?
如果忽略 @ngrx 最佳实践，性能可能会受到影响：=
- https://blog.strongbrew.io/Redux-best-practices
- 尽可能保持状态平坦
ngrx 使用 createSelector 创建的选择器被记忆化，这意味着它们只会在状态更改时触发更改。这是 performance-pro for ngrx，到 re-implement 这在海量服务中可能需要大量工作
what do we need to consider when implementing the NgRX?
尽快获得最佳实践。
我从事过一些 Angular 2+ 项目，但我仍然想知道为什么我们确实需要 NgRX。 我可以用服务来实现一切，而且它们似乎更容易理解。 我不确定这是不是因为我不熟悉 NgRX，但无论如何我找不到 NgRX 的特定用例。 谁能给我一些关于以下内容的解释？
- NgRx 和服务的状态实现之间的差异
- 每个实施的优缺点
- 我们在实现 NgRX 时需要考虑什么？
- 对性能有任何顾虑吗？
这将是一个相当 ngrx-pro post 因为我已经使用它近 3 年了。我已经看到很多次它偏离轨道并且管理 ngrx-state 变得很痛苦，但主要是由于忽视了应用程序架构和最佳实践。如果应用得当，编写和审查 ngrx 代码是一种乐趣，因为事物具有严格的结构。
恕我直言：它可以在任何应用程序中使用，在更大的应用程序中确实很有意义。 ngrx 可以为您做的所有事情也可以使用服务来构建，但是从长远来看 运行 会变得越来越难。当你意识到你需要它时，为时已晚。
这是一篇讨论这一切的文章。
https://blog.strongbrew.io/do-we-really-need-redux/
difference between state implementation by NgRx and Services
虽然 ngrx 对如何 read/update/write 数据持有相当多的意见，但服务留给开发人员更多的事情。我倾向于选择 CRUD 操作以保持一致性。
- Angular 服务通常公开
Observables，其中保存数据和功能以更新上述Observables中的数据。通常这意味着我们最终会在每个服务中进行 re-creating CRUD 操作。 ngrx将数据公开为selectors，update/delete 的功能为actions。除此之外还有effects来处理异步操作。读和写之间有明显的区别，因为逻辑发生在不同的地方，而不是服务 类，后者主要 all-in-one。- Angular 服务使得在某些 类 中构建私有状态管理变得非常容易，这通常是令人沮丧的。
pros and cons of each implementation
有一些东西使 ngrx 有价值，例如它的扩展，但需要正确使用和配置它们。对我来说主要价值是它提供的一致性。
- devtools 可以更容易地了解哪些值更新的时间和频率。使用控制台日志进行调试很痛苦：
- 有一个
@ngrx/entity-package 可以更轻松地管理集合，因为它提供了upsertOne或updateMany等具有 clearly-defined 类型的方法。它还通过生成选择器提供轻松访问： @ngrx/data是@ngrx/entity包的扩展，通过向 update/delete... 实体提供 API 方法，无需编写大量服务- 您可以随时使用自己的服务扩展
@ngrx/effects。
any concerns with performance?
如果忽略 @ngrx 最佳实践，性能可能会受到影响：=
- https://blog.strongbrew.io/Redux-best-practices
- 尽可能保持状态平坦
ngrx使用createSelector创建的选择器被记忆化，这意味着它们只会在状态更改时触发更改。这是 performance-pro forngrx，到 re-implement 这在海量服务中可能需要大量工作
what do we need to consider when implementing the NgRX?
尽快获得最佳实践。