angular - Redux 与 BehaviorSubject - 有什么区别？

Question

假设您是一名 Angular 开发人员，您可能拥有一项名为用户服务的服务。该服务有一个您的组件订阅的行为主题(请参阅 rxjs)，并且可以说该服务还有一些方法来更改用户状态。

您的顶级组件监听用户服务状态并将其输入到它的子组件。然后该子组件调用服务上的一个方法来更改用户状态，并且行为主题发出一个新值。现在你的组件监听得到一个更新的值并将它传递给它的子组件。

或者在另一个实现中，你有一堆组件在同一级别监听状态变化。调用一个服务方法来改变状态并发出状态，所有监听的组件都获得新状态。

在 Redux 方面，我是一个新手，但我知道有一个状态区域。您的组件改为写入状态并从那里收听状态。

我没看出区别？我知道 Redux 还允许您查看实际调用了哪些操作来更改状态，而在行为主体示例中，它们是完全分离的，并且不知道状态为何或如何更改的概念——它们只知道现在的状态。

有人可以解释一下吗？

Answer 1

当我遇到一个非常常见的用例时遇到了这个问题:开发一个可以从我的应用程序中的任何地方切换的加载器/微调器。

我自己也提出过类似的问题:redux 到底有什么好处，特别是当行为主体处理我当前的需求时。

我推荐这篇文章: https://blog.angular-university.io/angular-2-redux-ngrx-rxjs/

文章提到了应该使用商店的关键时间，以及一些好处:

• 将组件树向上注入(inject)到看起来自然超出范围的组件中时。 (无论如何使用 behaviorsubject 避免了这样的注入(inject))
• 性能、可测试性、工具、可预测性

它还提到了使用像 Redux 这样的商店的负面影响:

• store 确实解决了组件交互的问题，但它也产生了在您的应用程序中管理状态的需求，否则在使用其他解决方案时可能不存在这种需求。

看完所有视频并阅读所有文字后，我认为 Redux 很棒。我真的很想用它。但是，对于我当前仅共享单个对象的状态的用例:

{ show: true }

或

{ show: false }

当 rxjs/behaviorsubject 以很少的开销完全满足我的需求时，采用整个库来处理这种单一状态显然不是正确的选择。

文章中真正打动我的一句话:

如果你不知道你是否需要 Redux，那么你就不需要 Redux。

我认为这就是说，Redux 是为了解决一个巨大的问题:跨大型数据存储的数据不可变性。如果你没有那个问题......你还不需要 Redux。 :)