如何正确使用 ngrx 和 Angular 服务

Question

开始学习 Angular，但不确定如何使用 ngrx 构建结构。

简而言之，我有一个服务，其中有两个数组，以及以特定方式操作这些数组的方法。我创建了该服务，因为多个组件需要操作数组的逻辑。其中一些将使用这些数组之一的相同状态，一些将具有不同的状态。

不同的组件将访问此服务，对数组进行更改并使数组返回渲染。然而，在网上进行研究后，似乎常见的做法是保持服务无状态。然后我遇到了 ngrx 商店。

所以我想我可以将这些数组放在主存储中而不是放在服务中，所以它变成：

组件会使用service，操作数组，service会触发一个action，然后store会通知组件数组的变化

但是，请查看 ngrx https://ngrx.io/ generated/images/guide/store/state-management-lifecycle.png 中的图表。组件和服务之间会有一个箭头，当应用程序变得更大时，这似乎会造成混乱。

那么我应该如何处理这个问题呢？我在这里误解了什么吗？也许服务应该是一个组件（但是阅读https://angular.io/guide/styleguide#delegate-complex-component-logic-to-services，看起来我确实在做正确的事情，将逻辑移出组件到服务，使组件变得简单）。

任何意见是极大的赞赏

Answer 1

一些尝试帮助您了解 NgRx 并设计最适合您的架构的技巧：

您应该只有一个事实来源。这意味着仅将原始数据保留为状态。区分同一数据的多个视图或原始数据的突变非常重要。

状态通过操作转变为减速器函数。这些纯函数（reducer）将状态 A 转换为状态 B。例如：将一个新项目添加到数组中。

选择器专用于从存储中选择（提取）数据片段。您可以考虑数据库（状态）和 SQL Select（选择器）。

这意味着您可以根据特定组件的需要检索数组的数据子集、过滤、排序等。而且也是多个状态切片的组合，作为新类型返回。

有了 NgRx，服务有时确实会失去一些战略角色。根据我的观点和经验，服务主要用于对 api 后端的外部请求。

转换逻辑在reducer中，并且应该保持简单。提取逻辑（视图）位于选择器中。

为了保持这个组织清晰和可维护，最好使用单独的文件，例如：

您还应该区分两种类型的组件：

dump Components：只有UI组件，没有任何逻辑，没有对 NgRx、状态、服务的调用或依赖......只是@Input，并且@Output带有简单的数据。
容器或智能组件：将它们视为交通控制塔。它们依赖于 NgRx，可以调度操作并订阅状态更新（通过选择器）。它们组织从选择器和转储组件检索的数据之间的链接。