我正在从Angular的基础知识转向更多地了解最佳实践。我最近开始尝试采用更具反应性的方法，但有一件事我只是通过谷歌搜索找不到一个好的答案。
现在，我们可以在服务中使用以下简单方法：
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) })
}
现在，该服务的任何消费者都可以收听来自$的更改。但是，当然，您现在需要知道“分离”流与被调用方法之间存在连接。
如果看起来大多数教程都采用第一种方法，那么真的是反应式编程吗？什么是最好的解决方案？ }
答案 0 :(得分：3)
您的第二种方法绝对适用于您描述的用例。根据我的经验，大多数教程都是或者仅仅涵盖基础知识（即您的第一种方法），或者通过实施NgRx等状态管理库将其比第二种方法更进一步
使用状态管理库（ NgRx可能是您最好的选择，因为它由谷歌人员支持）可能被认为是最好的建立反应性应用时的实践。
从本质上讲，您获得的好处是集中的数据存储，应用程序中的每个组件或服务也可以订阅。有点像您在服务中使用subject创建的方案 - 仅用于比一个服务更大的范围。
为什么将NgRx仅仅考虑共享服务？
Redux - NgRx 确实是什么，是 Redux模式的Angular实现。 Redux模式，简要总结如下：
那么为什么这些点有什么好处呢？好吧，当你有一个非常严格和标准化的方法来管理你的应用程序中的状态时，调试变得更容易，因为你知道只能在一个地方修改状态。
让您的应用程序变得更加容易，因为您的所有实现都可以访问同一个商店（您可以拆分商店，但这是另一个主题）。
以下是一些关于这个主题的非常好的教程：