假设您是Angular开发者，您可能拥有一项名为User Service的服务。此服务有一个行为主题（请参阅rxjs），您的组件可以订阅，并且假设该服务还有一些方法可以更改用户状态。
您的顶级组件侦听用户服务状态并将其输入到其子组件。然后，该子组件调用服务上的方法来更改用户状态，并且行为主体发出新值。现在，您的组件侦听获取更新的值并将其传递给其子级。
或者在另一个实现中，您在同一级别拥有一堆组件来侦听状态更改。一个调用服务方法来改变状态并发出状态，所有组件监听都会获得新状态。
在Redux方面，我很新，但我知道有一个州区。你的组件改为写入状态并从那里听取状态。
我看不出差异？我知道Redux还允许您查看实际调用哪些操作来更改状态，而在行为主题示例中，它们完全解耦，并且没有关于状态更改的原因或方式的概念 - 他们只知道状态现在是什么。
有人可以解决一些问题吗？
答案 0 :(得分：5)
当我遇到一个非常常见的用例时，我遇到了这个问题：开发一个可以从我的应用程序中的任何位置切换的加载程序/旋转程序。
我本人也提出了类似的问题：redux到底有什么好处，尤其是当行为主体满足了我当前的需求时。
我推荐这篇文章： https://blog.angular-university.io/angular-2-redux-ngrx-rxjs/
本文提到应使用商店的关键时间，以及一些好处：
它还提到了使用Redux这样的商店的负面影响：
观看完所有视频并阅读所有文字后，我认为Redux很棒。我真的很想使用它。但是，对于我当前的共享单个对象状态的用例，
{ show: true }
或
{ show: false }
当rxjs / behaviorsubject完全满足我的需要且开销很小时，采用整个库仅处理单个状态显然不是正确的选择。
这篇文章真正打动了我：
如果您不知道是否需要Redux，就不需要Redux。
我认为这就是Redux在这里解决的一个巨大问题：大型数据存储中的数据不变性。如果您没有这个问题，那么您还不需要Redux。 ：）
答案 1 :(得分：3)
我有一个 Angular应用程序，该应用程序使用全球服务中的行为主题实现了保存和更新状态，我在整个应用程序中观察到的变化
该代码清晰易读，可以完美运行而没有问题，可以实现目标，并且易于排除故障。 ?
话虽如此，我花了一些时间尝试使用 ngrx 和迁移到 redux / flux模式，同时我得到了具有一个中央的，不可变的状态存储库，感觉就像我在整个应用程序中创建了一个极大的复杂度，以便正确地实现它，并且此后放弃了该库。
需要将副作用与 ngrx效果集成在一起，这确实使使用它感到沮丧。代码不可靠，我开始遇到问题，而在运行时出现了多个可观察到的订阅，更不用说其他与观察变化，易读性和相关性有关的其他问题了。组织我的代码。
一天结束时，最好的不是商品的敌人吗？
答案 2 :(得分：2)
Redux是Flux模式的一种实现。这意味着行动和减少者是模式的一部分，并且具有提供不可变状态的单一事实来源。使用提供一段不可变状态的服务只是redux（或其他使用像ngRx这样的Flux模式的库）提供的一部分。
需要注意的是，ngRx（类似于针对angular的observable所做的redux的lib）使用BehaviorSubjects作为状态（或以ngRx术语存储）。所以使用BehaviorSubject绝对是它的一部分！
使用Subjects时需要注意的是尝试将它们设为私有，并允许组件通过返回Observable上的asObservable函数的方法来订阅它们。它可以让你免于一些令人头疼的事情：）
答案 3 :(得分：1)
我将BehaviorSubject与redux结合在一起， 您假设将其用作常规可观察的 当您设置新值时，库会将值克隆为新值并调度自动操作，因此您可以使用redux-devtools-extension对其进行调试。 https://www.npmjs.com/package/redux-behavior-subject
答案 4 :(得分：0)
从那以后，我意识到目的是不同的。使用行为主题很好-意图是存储一些状态，并且您可能具有相同的状态或一定数量的交叉状态，存储在整个应用程序的许多行为主题中（您不应该这样做，但它可能是有效的）。 / p>
redux的意图不同。当状态在整个应用程序中仅存储和更改一个位置时，它提供了一种使用单一事实来源的方法。数据也是不可变的。由于这两个因素，有可能建立关于数据突变以及来自系统哪个区域的哪些事件导致这些突变的稳健一致的时间表，这使聪明的人可以编写聪明的工具来“倒带”调试您的应用程序时间”。
这里的其他答案很好，但我认为它们处理实现细节，例如动作（显而易见的）和化简（突变函数），真正的收获是差别是微妙的，因为它在于两者之间的意图差异。通量模式和观察者模式。
通量模式如前所述-可以以不变的单一真理方式观察到的数据存储。我相信您可以说这是使用状态模式和观察者模式的复合模式。
观察者模式是通过侦听事件（可能是相同的事件）来解耦代码，并以不同的单一职责运行不同的代码区域以确保解耦。例如，用户通过弹出窗口在论坛上更改其用户名，他们在打开页面上发布的所有帖子都应使用其新名称进行更新，并且显示在网站标题右上角的用户名也应更改。这些是不同的责任领域。