Redux Vs BehaviourSubject - 有什么区别？

Question

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

您的顶级组件侦听用户服务状态并将其输入到其子组件.然后,该子组件调用服务上的方法以更改用户状态,并且行为主体发出新值.现在,您的组件侦听获取更新的值并将其传递给其子级.

或者在另一个实现中,您在同一级别拥有一堆组件来监听状态更改.一个调用服务方法来改变状态并发出状态,所有组件监听都获得新状态.

在Redux方面,我很新,但我知道有一个州区.你的组件改为写入状态并从那里听取状态.

我没看到差异？我知道Redux还允许您查看实际调用哪些操作来更改状态,而在行为主题示例中,它们完全解耦,并且没有关于状态更改的原因或方式的概念 - 他们只知道状态现在是什么.

有人可以解决一些问题吗？

Answer 1

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

我自己提出了一个类似的问题:redux的好处究竟是什么,特别是当行为主体处理我当前的需求时.

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

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

• 将组件树注入到自然超出范围的组件中时.(使用actsubject避免像这样注入)
• 性能,可测试性,工具,可预测性

它还提到使用像Redux这样的商店的负面消息:

• 该商店确实解决了组件交互的问题,但它也创建了在应用程序中管理状态的需求,否则在使用其他解决方案时可能不存在.

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

{ show: true }

要么

{ show: false }

当rxjs/behaviorsubject以非常小的开销完全满足我的需要时,采用整个库来处理这种单一状态显然不是正确的选择.

这篇文章真的让我印象深刻:

如果您不知道是否需要Redux,则不需要Redux.

我想也就是说,Redux在这里解决了一个巨大的问题:跨大型数据存储的数据不变性.如果你没有那个问题......你还不需要Redux.:)

Answer 2

我有一个使用全局服务中的行为主体实现的Angular 应用程序，用于保存和更新状态，我观察到整个应用程序中的更改。

代码非常清晰，工作完美，没有问题，实现了目标，并且很容易排除故障。

话虽如此，我花时间尝试 使用ngrx迁移到redux/flux 模式，虽然我得到了拥有一个中央且不可变的状态存储的概念和好处，但感觉我在整个过程中创造了巨大的复杂性我的应用程序为了正确实现它，并从此放弃了该库。

必须将副作用与ngrx 效果相结合的需要确实让工作变得令人沮丧。代码感觉不可靠，我开始遇到问题，而在运行时期间开始出现多个可观察订阅，更不用说与观察代码的更改、易读性和组织相关的各种其他问题了。

归根结底，最好的难道不是好的敌人吗？

Answer 3

Redux 是 Fl​​ux 模式的一个实现。这意味着 action 和 reducer 是模式的一部分，并且具有提供不可变状态的单一事实来源。使用提供一段不可变状态的服务只是 redux（或其他使用 Flux 模式的库，如 ngRx）所提供的一部分。

需要注意的是 ngRx（一个类似于 redux 的 lib，围绕 observables 为 angular 制作）使用 BehaviorSubjects 作为状态（或以 ngRx 术语存储）。所以使用 BehaviorSubject 绝对是其中的一部分！

使用 Subjects 时要注意的是尝试将它们设为私有并允许组件通过返回 Observable 上的 asObservable 函数的方法订阅它们。它可以使您免于以后的一些头痛:)

Answer 4

从那以后我意识到意图是不同的。使用行为主题很好 - 目的是存储某些状态，并且您可能具有相同的状态或一定量的交叉状态，存储在应用程序中的许多行为主题中（您不应该这样做，但它可能是有效的）。

redux 的意图是不同的。它提供了一种具有单一事实来源的方法，因为状态仅在整个应用程序中的一个位置存储和变异。数据也是不可变的。由于这两个因素，可以建立一个关于数据突变以及系统哪个区域的事件导致这些突变的强大一致的时间表，这使得聪明的人可以编写聪明的工具来通过“倒带”来调试应用程序时间'。

这里的其他答案很好，但我觉得它们处理实现细节，例如操作（显而易见）和减速器（突变函数），真正的要点是差异很微妙，因为它在于通量模式和通量模式之间的意图差异。观察者模式。

通量模式如所描述的那样 - 您可以以不可变的单一事实方式观察到的数据存储。我相信你可以说它是使用状态模式和观察者模式的复合模式。

观察者模式是通过监听事件（可能是相同的事件）来解耦代码，并运行具有不同单一职责的不同区域的代码以确保解耦。例如，用户通过弹出窗口更改其在论坛上的用户名，他们在打开页面上发布的所有帖子都应使用其新名称进行更新，并且网站标题右上角显示的用户名应更改。这些是不同的责任领域。