redux 和 reflux 在使用基于 react 的应用程序中的核心区别是什么？

Question

最近初步研究开发一个电商网站，发现Facebookredux and reflux both come from flux architecture，而且都比较受欢迎。我对两者之间的区别感到困惑。

我应该什么时候使用 redux 与 reflux，在电子商务 Web 应用程序的开发阶段哪个最灵活？

Answer 1

Flux、Reflux 和 Redux（以及许多其他类似的库）都是处理横向数据管理的不同方式。

基本的 React 组件可以很好地处理父子关系，但是当您必须从应用程序的不同部分提供和更新没有直接连接的数据时，它很快就会变得混乱。这些库提供存储和操作（以及其他机制）来维护和更新此类数据。

Flux 是 Facebook 开发的原始解决方案（就像 React 一样），它功能强大但可能不是最简单或可读的。 Reflux 的开发部分是为了使其更容易和更清晰。主要区别是在 Reflux 中，每条数据都有自己的存储和操作，这使得它非常可读和易于编写。不幸的是，Reflux 不再那么积极地开发了，作者正在寻找维护者。但总而言之，我会说 Reflux 是 Flux 的更优雅的替代品。

Redux 是另一种解决方案，目前已成为最流行的解决方案。它的优点是它提供了具有不可变内容的嵌套商店，因此您可以轻松实现 previous/next 功能并具有对商店的许多部分产生影响的横向操作。 redux 的缺点是它非常冗长，并且比 Flux 或 Reflux 有更多的概念。对于相同的基本操作，它将需要更多的代码，并且异步实现并不是最干净的。它绝对强大且可扩展。

这里有一个 link 更广泛地讨论了它：http://jamesknelson.com/which-flux-implementation-should-i-use-with-react/

Answer 2

我想再写一个回答，重点说一下Reflux和Redux的具体区别。 @Mijamo 深入探讨了为什么它们起源于不同事物的核心，如果您有上下文，这是一个很好的总结，但我提出这个问题是为了从发展的角度具体了解两者之间的区别。看到我是如何进入并阅读所有内容的，我想写一个答案。我将使用更多代码示例更新此答案。

通量（快速概览）

在我们开始之前，我认为我们应该牢记的一件事是考虑当前的 Flux 以及它当前如何处理扩展具有许多组件或许多需要管理的不同状态的应用程序.这是一个很好的 talk at React NYC: Scaling Flux 解决问题的方法，他们得出的解决方案与 Reflux 和 Redux 允许您做的事情相差不远，但简而言之，一个大问题是“什么当我们的组件具有一些它们都需要记住的共享状态时，我们会怎么做？我们如何处理和扩展它？”最终，许多这些框架得出的答案是我们需要这个全球国家的想法。不可避免地，这两个框架都引入了一些类似的概念来实现这一点，我们将在下面进行介绍。

因为需要参考Flux的对比，所以我只想展示一个quick overview way Flux works下图：

反流

在 Reflux 中，没有调度器，View Components 直接通过 actions 通过组件进行通信。

+---------+       +--------+       +-----------------+
¦ Actions ¦------>¦ Stores ¦------>¦ View Components ¦
+---------+       +--------+       +-----------------+
     ^                                      ¦
     +--------------------------------------+

就它与Flux的区别而言，并没有太多。您仍然创建自己的操作并创建自己的商店，并且您仍然让商店收听操作。我认为最大的区别在于，为了让 View 组件直接向商店提交操作而不是通过调度程序，组件有一个商店属性，它来自 Reflux.Component 而不是 React.Component 这样它就可以直接连接到商店。即这个例子

class MyComponent extends Reflux.Component
{
    constructor(props)
    {
        super(props);
        this.state = {}; // our store will add its own state to the component's
        this.store = StatusStore; // <- just assign the store class itself
    }

    render()
    {
        var flag = this.state.flag; // <- flag is mixed in from the StatusStore
        return <div>User is {flag}</div>
    }
}

您还可以连接到多个商店（我相信有一个名为 stores 的道具需要一个数组，Reflux 还附带了编辑 mapStoreToState 的功能，以备您需要具体控制商店如何将状态传递给组件。

自然地，因为您使用的是 Reflux 附带的组件，您可能应该阅读他们的 documentation on Reflux Component 以及如何正确制作组件并牢记这一点

我要注意的最后一件事是上面我提到的大问题是全局状态以及它如何解决这个问题。 Reflux 确实有一个 Reflux.GlobalState 可以贡献，只要你在你的商店上设置 ids。上面的 link 更详细地介绍了它，但是有了这个，您可以通过 Reflux.GlobalState.[StoreID].[property] 访问它们，其中 StoreID 是您分配给商店的 ID，而 property 是实际的您要访问的状态。

Redux

Redux 本身改变了很多东西，也扼杀了调度器的想法。在我真正深入之前，我想强调一下他们在文档中提到的 three principles。

单一事实来源
状态为只读
使用纯函数进行更改

在 Redux 中，您实际上只有一个全局状态需要处理，那就是您的应用程序的全局状态（解决大问题）。虽然您仍然有操作和存储，但存储本身只负责在全局状态树中跟踪它们自己的状态，允许您分派操作以更改状态树，并允许您访问状态。您还可以通过 subscribe 在这些商店中放置听众。

前两个原则中有很大的动机。在 Flux 甚至 Reflux 中，如果你想确保没有任何东西在你不想要的时候改变状态（因为从技术上讲你可以随时访问和更改商店中的状态），你会依赖像 ImmutableJS 以确保您没有意外地改变状态。另一方面，Redux 做到了这一点，因此您只能通过 stores/selectors 访问状态，并且只能通过调度操作进行更改（第三个原则）。

需要注意的一件有趣的事情是，尽管 Reflux 和 Flux 具有操作，您可以在商店中的什么地方收听并确定要执行的状态更改，而 Redux 中的商店只需发送一条包含您想要的有效负载的消息，然后就可以了通过一个巨大的 switch 语句来确定它应该如何处理状态树——这就是他们所说的 reducer。这与 Flux 在其 Stores 中具有 reduce 的方式没有任何不同，但 Redux 将这个概念作为自己的东西撕掉并且您的全局状态树经过 rootReducer （Redux 为您提供了一个很好的功能到 combineReducers 并制作一个 rootReducer）。考虑它的一个好方法是将更改发送到巨型状态树，然后无论您想要什么更改，它都会减少或压缩到您想要的最终状态。这实际上影响了 redux 设置很多东西的方式，所以它告诉 React 如何重新渲染（假设你正在使用 Redux 和 React）。

Redux 的 data flow 在我上面提到的 link 中讨论得非常好，但我附上了一个非常好的信息图

所以核心差异确实是

Redux 有一种完全不同的状态管理方法——它接受了这样的想法，即存在一个全局状态，如果你想进行更改，那不可避免地应该发生在那里 以一种非常具体的方式（您如何处理哪些组件可以访问哪些状态取决于您）。
Reflux 确实试图支持让组件能够访问多个商店，而不必改变太多 Flux 最初的内容（我想认为 Reflux 就是 Flux应该是）。
Redux 真正改变了状态树的管理方式并提供了存储不同的职责，并改变状态信息的方式被向下映射到组件，而 Reflux 只是撕掉了中间人，这样你就可以让你的组件访问任何商店他们需要更轻松。

希望这能让人们更深入地了解它们之间的核心差异。

redux 和 reflux 在使用基于 react 的应用程序中的核心区别是什么？

What is the core difference of redux & reflux in using react based application?

software-design

flux

reactjs

refluxjs

redux

通量（快速概览）

反流

Redux