Angular 状态管理 - 存储还是有状态服务？ [关闭]答案

【问题标题】：Angular state management - Store or Stateful services? [closed]Angular 状态管理 - 存储还是有状态服务？ [关闭]
【发布时间】：2018-12-25 13:08:30
【问题描述】：

我们目前有一个中型 Angular 6（prod bundle = 5MB）应用程序，其中 ngrx/store 实现了状态管理。

我们选择 ngrx/store 是因为当时 (NG2) 每个人都使用它，并且以这种方式存储状态和访问状态似乎是个好主意。换句话说：错误的原因。

感觉越来越像一个不需要的间接层，因为服务可以保持状态并返回流以访问应用程序状态的一部分，而样板文件少得多（即使使用 NGXS）。

问题

从架构的角度来看，我们为什么要选择 ngrx/store 或 NGXS 而不是普通的有状态服务？

请只讨论现实世界的论点，不要理论或纯粹的论点。

如果处理得当，一些带有少量流的普通 @Injectable 服务会产生干净的代码、没有样板代码和状态的全部责任。即使是不变性，我们也可以轻松处理。

（是的，我知道如果你让它们正常工作，比如在 HMR 中恢复状态和检查状态，会有一些技术优势，但我们从来没有让它们始终如一地正常工作）

【问题讨论】：

我在这里遇到同样的问题。
所有解决方案都暗示使用贫血数据模型，即没有行为的普通对象。这样，您就不能对其进行强制验证或以任何其他方式确保模型实际上处于一致状态。此外，我不喜欢依赖 Store 来选择和调度，而不仅仅是我真正使用的状态对象......与 NGRX 相比，NGXS 使它更符合 Angular，但在这些方面它仍然是间接的.
这篇博文涵盖了您需要的所有信息，并且在总体上理解应用程序状态管理方面也提供了非常丰富的信息。读一读：Angular Application State Management: You Do (Not) Need External Data Stores

【解决方案1】：

使用 NgRX 有几个很好的理由：

1) 它可以防止您需要大量的小服务，这些服务比单个 NgRx 存储更难管理和跟踪。

2) 存储提供客户端缓存，因此您无需每次都从服务器重新获取数据……仅在需要时。是的，您也可以在自己的服务中做到这一点，只需使用更多代码。

3) 使用选择器，任何组件都可以很容易地收到对特定数据的任何更改的通知，从而使整个系统的通知变得容易……即使更改为多个页面。同样，您可以使用 Subject/BehaviorSubject 在自己的服务中执行此操作，但为什么要重新发明轮子。

4) 可以使用 Angular CLI 生成标准模式和流程，从而更容易确保应用程序的所有代码保持一致。

5) 您可以使用调试工具轻松查看发生了什么。在我最近的几次演讲中，许多开发人员想要迁移到 NgRX 只是来实现这个功能。 :-) 你说你很难让它正常工作？

【讨论】：

DevTools 工作正常，但不幸的是不能与 HMR 一起使用。这可能是我们做错了什么。有时商店只是没有正确恢复。我可以想象将我们的状态放在一个具有正确类型的状态对象的 StateService 中并实现一小段代码，而没有我们现在拥有的所有化简器、动作、效果等样板。我只是越来越难以向新开发者证明和解释我们为什么这样做。
考虑发布到 NgRX 的 github 问题。团队中的开发人员非常乐于助人！
我可能会因为这样说而被钉死在十字架上……但对于新开发人员，我有一门课程：“Angular NgRX：入门”可能会有所帮助。
不，你不会被钉死在十字架上 :) 我有很多关于如何实施和使用 NgRX/store 的资料，但不是确切的原因，这是我的问题所在。
感谢您的宝贵时间。我目前没有有效的 Pluralsight 帐户，因此无法观看。如果不存在具有多个修改状态的源的复杂共享状态，我仍然不相信我们仍然需要 NgRx/store。我会继续寻找答案。