Redux作者在这里!

Redux和Flux没有什么不同。总的来说，它具有相同的架构，但Redux能够通过使用函数组合(Flux使用回调注册)来减少一些复杂性。

在Redux中没有根本的区别，但我发现它使某些抽象更容易，或者至少可以实现，而这些抽象在Flux中很难或不可能实现。

减速器组成

Take, for example, pagination. My Flux + React Router example handles pagination, but the code for that is awful. One of the reasons it's awful is that Flux makes it unnatural to reuse functionality across stores. If two stores need to handle pagination in response to different actions, they either need to inherit from a common base store (bad! you're locking yourself into a particular design when you use inheritance), or call an externally defined function from within the event handler, which will need to somehow operate on the Flux store's private state. The whole thing is messy (although definitely in the realm of possible).

另一方面，用Redux进行分页则是由于减速器组成的自然。它一直都是减速器，所以你可以写一个减速器工厂来生成分页减速器，然后在你的减速器树中使用它。之所以如此简单，关键在于在Flux中，存储是扁平的，但在Redux中，reducer可以通过函数组合嵌套，就像React组件可以嵌套一样。

这种模式还支持一些很棒的特性，比如无需用户代码的撤销/重做。你能想象在Flux应用中插入撤销/重做只需两行代码吗?几乎没有。与Redux，它是-再次，感谢减速器组成模式。我需要强调的是，这并不是什么新鲜事——这是Elm Architecture中首创并详细描述的模式，Elm Architecture本身就受到Flux的影响。

服务器呈现

人们用Flux在服务器上渲染得很好，但看到我们有20个Flux库，每个库都试图让服务器渲染“更容易”，也许Flux在服务器上有一些粗糙的边缘。事实上，Facebook并没有做太多的服务器渲染，所以他们并不太关心这个问题，而是依靠生态系统来让它变得更容易。

在传统的Flux中，商店是单一的。这意味着很难在服务器上分离不同请求的数据。不是不可能，但很难。这就是为什么大多数Flux库(以及新的Flux Utils)现在建议您使用类而不是单例，这样您就可以为每个请求实例化存储。

您仍然需要在Flux中解决以下问题(您自己或您最喜欢的Flux库(如flumox或Alt)的帮助下):

如果存储是类，我如何创建和销毁他们与dispatcher每个请求?什么时候登记店铺? 如何为存储中的数据补水，然后在客户机上再补水?我需要为此实现特殊的方法吗?

诚然，Flux框架(不是普通的Flux)可以解决这些问题，但我发现它们过于复杂。例如，Flummox要求您在存储中实现serialize()和deserialize()。Alt通过提供takeSnapshot()更好地解决了这个问题，它可以自动在JSON树中序列化您的状态。

Redux走得更远:因为只有一个存储(由许多还原器管理)，所以不需要任何特殊的API来管理(再)水合作用。您不需要“刷新”或“补充”存储—只有一个存储，您可以读取它的当前状态，或者使用新状态创建一个新存储。每个请求获得一个单独的存储实例。阅读更多关于Redux服务器渲染的信息。

同样，这是一个在Flux和Redux中都可能出现的情况，但是Flux库通过引入大量API和约定来解决这个问题，而Redux甚至不需要解决这个问题，因为由于概念上的简单性，它在一开始就没有这个问题。

开发人员的经验

实际上，我并没有打算让Redux成为一个流行的Flux库——我是在写关于时间旅行热重载的reacteeurope演讲时写的。我有一个主要目标:通过划掉动作来改变减速器代码，甚至“改变过去”，并看到状态被重新计算。

我还没有见过任何一个Flux库能够做到这一点。React Hot Loader也不允许你这样做——事实上，如果你编辑Flux存储，它就会崩溃，因为它不知道如何处理它们。

当Redux需要重新加载减速器代码时，它会调用replaceReducer()，应用程序将使用新代码运行。在Flux中，数据和函数纠缠在Flux存储中，因此不能“仅仅替换函数”。此外，您还必须以某种方式向dispatcher重新注册新版本——Redux甚至没有这种功能。

生态系统

Redux拥有丰富且快速增长的生态系统。这是因为它提供了一些扩展点，比如中间件。它在设计时考虑到了日志记录、对承诺的支持、可观察对象、路由、不可变性开发检查、持久性等用例。并不是所有这些都有用，但是能够使用一组可以轻松组合在一起工作的工具是很好的。

简单

Redux保留了Flux的所有优点(记录和重放操作、单向数据流、依赖突变)，并在不引入Dispatcher和存储注册的情况下增加了新的优点(易于撤销重做、热重新加载)。

保持简单是很重要的，因为它能让你在实现更高层次的抽象时保持理智。

与大多数Flux库不同，Redux API表面很小。如果去掉开发人员警告、注释和健全性检查，它就是99行。不需要调试复杂的异步代码。

你可以读懂Redux的所有内容。

---

请参阅我对使用Redux与Flux相比的缺点的回答。

根据这篇文章: https://medium.freecodecamp.org/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075

你最好使用MobX来管理应用中的数据以获得更好的性能，而不是Redux。

Redux作者在这里!

Redux和Flux没有什么不同。总的来说，它具有相同的架构，但Redux能够通过使用函数组合(Flux使用回调注册)来减少一些复杂性。

在Redux中没有根本的区别，但我发现它使某些抽象更容易，或者至少可以实现，而这些抽象在Flux中很难或不可能实现。

减速器组成

Take, for example, pagination. My Flux + React Router example handles pagination, but the code for that is awful. One of the reasons it's awful is that Flux makes it unnatural to reuse functionality across stores. If two stores need to handle pagination in response to different actions, they either need to inherit from a common base store (bad! you're locking yourself into a particular design when you use inheritance), or call an externally defined function from within the event handler, which will need to somehow operate on the Flux store's private state. The whole thing is messy (although definitely in the realm of possible).

另一方面，用Redux进行分页则是由于减速器组成的自然。它一直都是减速器，所以你可以写一个减速器工厂来生成分页减速器，然后在你的减速器树中使用它。之所以如此简单，关键在于在Flux中，存储是扁平的，但在Redux中，reducer可以通过函数组合嵌套，就像React组件可以嵌套一样。

这种模式还支持一些很棒的特性，比如无需用户代码的撤销/重做。你能想象在Flux应用中插入撤销/重做只需两行代码吗?几乎没有。与Redux，它是-再次，感谢减速器组成模式。我需要强调的是，这并不是什么新鲜事——这是Elm Architecture中首创并详细描述的模式，Elm Architecture本身就受到Flux的影响。

服务器呈现

人们用Flux在服务器上渲染得很好，但看到我们有20个Flux库，每个库都试图让服务器渲染“更容易”，也许Flux在服务器上有一些粗糙的边缘。事实上，Facebook并没有做太多的服务器渲染，所以他们并不太关心这个问题，而是依靠生态系统来让它变得更容易。

在传统的Flux中，商店是单一的。这意味着很难在服务器上分离不同请求的数据。不是不可能，但很难。这就是为什么大多数Flux库(以及新的Flux Utils)现在建议您使用类而不是单例，这样您就可以为每个请求实例化存储。

您仍然需要在Flux中解决以下问题(您自己或您最喜欢的Flux库(如flumox或Alt)的帮助下):

如果存储是类，我如何创建和销毁他们与dispatcher每个请求?什么时候登记店铺? 如何为存储中的数据补水，然后在客户机上再补水?我需要为此实现特殊的方法吗?

诚然，Flux框架(不是普通的Flux)可以解决这些问题，但我发现它们过于复杂。例如，Flummox要求您在存储中实现serialize()和deserialize()。Alt通过提供takeSnapshot()更好地解决了这个问题，它可以自动在JSON树中序列化您的状态。

Redux走得更远:因为只有一个存储(由许多还原器管理)，所以不需要任何特殊的API来管理(再)水合作用。您不需要“刷新”或“补充”存储—只有一个存储，您可以读取它的当前状态，或者使用新状态创建一个新存储。每个请求获得一个单独的存储实例。阅读更多关于Redux服务器渲染的信息。

同样，这是一个在Flux和Redux中都可能出现的情况，但是Flux库通过引入大量API和约定来解决这个问题，而Redux甚至不需要解决这个问题，因为由于概念上的简单性，它在一开始就没有这个问题。

开发人员的经验

实际上，我并没有打算让Redux成为一个流行的Flux库——我是在写关于时间旅行热重载的reacteeurope演讲时写的。我有一个主要目标:通过划掉动作来改变减速器代码，甚至“改变过去”，并看到状态被重新计算。

我还没有见过任何一个Flux库能够做到这一点。React Hot Loader也不允许你这样做——事实上，如果你编辑Flux存储，它就会崩溃，因为它不知道如何处理它们。

当Redux需要重新加载减速器代码时，它会调用replaceReducer()，应用程序将使用新代码运行。在Flux中，数据和函数纠缠在Flux存储中，因此不能“仅仅替换函数”。此外，您还必须以某种方式向dispatcher重新注册新版本——Redux甚至没有这种功能。

生态系统

Redux拥有丰富且快速增长的生态系统。这是因为它提供了一些扩展点，比如中间件。它在设计时考虑到了日志记录、对承诺的支持、可观察对象、路由、不可变性开发检查、持久性等用例。并不是所有这些都有用，但是能够使用一组可以轻松组合在一起工作的工具是很好的。

简单

Redux保留了Flux的所有优点(记录和重放操作、单向数据流、依赖突变)，并在不引入Dispatcher和存储注册的情况下增加了新的优点(易于撤销重做、热重新加载)。

保持简单是很重要的，因为它能让你在实现更高层次的抽象时保持理智。

与大多数Flux库不同，Redux API表面很小。如果去掉开发人员警告、注释和健全性检查，它就是99行。不需要调试复杂的异步代码。

你可以读懂Redux的所有内容。

---

请参阅我对使用Redux与Flux相比的缺点的回答。

2018年年中，一个新的react/redux采用者从(几年的)ExtJS迁移过来:

在redux学习曲线向下滑动之后，我有同样的问题，并认为纯通量会像OP一样更简单。

我很快就看到了redux对flux的好处，就像上面的答案中提到的那样，并将其应用到我的第一个应用程序中。

在再次掌握锅炉板的同时，我尝试了其他一些国家管理libs，我发现最好的是rematch。

它比普通的redux更直观，它减少了90%的样板文件，减少了我花在redux上的75%的时间(我认为一个库应该这样做)，我能够让几个企业应用立即运行起来。

它还使用相同的redux工具运行。这是一篇很好的文章，涵盖了一些好处。

因此，对于任何其他到达这篇So帖子搜索“更简单的redux”的人，我建议尝试它作为一个简单的redux的替代品，它具有所有的好处和1/4的模板。

我用Flux工作了很长时间，现在用Redux工作了很长时间。正如Dan指出的那样，这两种架构并没有太大的不同。Redux让事情变得更简单、更清晰。它在Flux的基础上教给你一些东西。比如Flux就是一个单向数据流的完美例子。关注点分离，数据、操作和视图层分离。在Redux中，我们有同样的东西，但我们也学习了不变性和纯函数。

你可能最好从Dan Abramov的这篇文章开始阅读，他在那里讨论了Flux的各种实现以及他们在写redux时的权衡: 通量框架的演化

其次，你链接到的动机页面并没有真正讨论Redux的动机，而是讨论Flux(和React)背后的动机。三个原则是更具体的Redux，但仍然没有处理与标准Flux架构的实现差异。

Basically, Flux has multiple stores that compute state change in response to UI/API interactions with components and broadcast these changes as events that components can subscribe to. In Redux, there is only one store that every component subscribes to. IMO it feels at least like Redux further simplifies and unifies the flow of data by unifying (or reducing, as Redux would say) the flow of data back to the components - whereas Flux concentrates on unifying the other side of the data flow - view to model.