Angular 服务 : best pratice for observables

Question

我正在从 Angular 基础知识转向学习更多最佳实践。我最近开始尝试采用一种更具 react 性的方法，但有一件事我无法通过简单的谷歌搜索找到好的答案。

现在，我们可以在服务中使用以下简单方法:

   public getSomething(): Observable<Something>
   {
      return this._http.get("api path")
   }

因此，在调用组件中，显然，现在我们可以订阅并在流式传输更改时得到通知。但是，如果应用程序的多个部分需要通知此更改怎么办？

因此，作为替代方案，我们可以执行以下操作:

   private _somethingSubject: Subject<Something> = new Subject<Something>();
   public someThing$: Observable<Something> = this._somethingSubject.asObservable(); 

   public getSomething()
   {
      return this._http.get("api path")
         .subscribe((something) => { this._somethingSubject.next(something) }) 
}

现在，该服务的任何消费者都可以监听 something$ 的变化。但是，当然，您现在需要知道“分离的”流与调用的方法之间存在联系。

似乎大多数教程都采用第一种方法，但这真的是响应式(Reactive)编程吗？什么是最好的解决方案？

Answer 1

第二种方法对于您描述的用例绝对有效。根据我的经验，大多数教程要么只是涵盖基础知识(即您的第一种方法)，要么通过实现状态管理库(例如 NgRx)比第二种方法更进一步 em>.

NgRx - 状态管理

使用状态管理库(NgRx 可能是您的最佳选择，因为它得到了 google 人员的支持)可能被认为是最佳选择在构建响应式应用程序时练习。

本质上，您获得的好处是一个集中式数据存储，应用程序中的每个组件或服务也可以订阅。有点像您在服务中使用 subject 创建的场景 - 仅适用于比一项服务更大的范围。

为什么考虑 NgRx 而不是共享服务？

Redux - NgRx 实际上是 Redux 模式 的 Angular 实现。 Redux 模式非常简短地总结为:

• 您的所有状态所在的集中式商店
• 负责更改状态的集中位置(您的 Reducers)
  • 你的状态是不可变的
  • 您的 reducer 函数只能由某人调度 所谓的操作

那么为什么这些点有好处呢？好吧，如果您有一种非常严格和标准化的方法来管理应用程序中的状态，调试就会变得容易，因为您知道只能在一个地方修改状态。

让您的应用程序响应式也更容易，因为您的所有实现都可以访问同一个商店(您可以拆分商店，但这是另一个主题)。

这里有一些关于这个主题的非常好的教程:

• Managing State in Angular Apps with ngrx/store and ngrx/effects (Part 1)
• Using NgRx 4 to Manage State in Angular Applications
• Managing State in Angular with ngrx/store
• NgRx on GitHub