这是Redux / Flux的简单解释。 Redux没有分派器。它依赖于称为约简的纯函数。它不需要调度程序。每个操作由一个或多个简化器处理，以更新单个存储。由于数据是不可变的，reducers返回一个新的更新状态来更新存储

更多信息Flux vs 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.

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相比的缺点的回答。

我是一个早期的采用者，并使用Facebook Flux库实现了一个中等大小的单页面应用程序。

虽然我有点晚了，但我要指出的是，尽管我寄予了最大的希望，但Facebook似乎认为他们的Flux实现是一个概念的证明，它从未得到应有的关注。

我鼓励您使用它，因为它揭示了Flux架构的更多内部工作原理，这非常有教育意义，但与此同时，它没有提供像Redux这样的库所提供的许多好处(这些好处对于小型项目并不那么重要，但对于大型项目非常有价值)。

我们已经决定继续前进，我们将移动到Redux，我建议你也这样做;)

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

在Quora上，有人说:

首先，完全可以不用React编写应用程序 通量。

另外，我创建了这个可视化图表来快速展示两者的视图，可能是对那些不想阅读整个解释的人的快速回答:

但如果你仍然有兴趣了解更多，请继续阅读。

我相信你应该从纯React开始，然后学习Redux和Flux。 在你有一些React的实际经验之后，你会看到 Redux是否对你有帮助 也许你会觉得Redux完全适合你的应用，也可能适合你自己 会发现Redux在试图解决一个你没有的问题 真正的体验。 如果直接从Redux开始，可能会以过度设计告终 代码，更难维护的代码，甚至有更多的错误 回来的。

Redux文档:

Motivation As the requirements for JavaScript single-page applications have become increasingly complicated, our code must manage more state than ever before. This state can include server responses and cached data, as well as locally created data that has not yet been persisted to the server. UI state is also increasing in complexity, as we need to manage active routes, selected tabs, spinners, pagination controls, and so on. Managing this ever-changing state is hard. If a model can update another model, then a view can update a model, which updates another model, and this, in turn, might cause another view to update. At some point, you no longer understand what happens in your app as you have lost control over the when, why, and how of its state. When a system is opaque and non-deterministic, it's hard to reproduce bugs or add new features. As if this wasn't bad enough, consider the new requirements becoming common in front-end product development. As developers, we are expected to handle optimistic updates, server-side rendering, fetching data before performing route transitions, and so on. We find ourselves trying to manage a complexity that we have never had to deal with before, and we inevitably ask the question: Is it time to give up? The answer is No. This complexity is difficult to handle as we're mixing two concepts that are very hard for the human mind to reason about: mutation and asynchronicity. I call them Mentos and Coke. Both can be great when separated, but together they create a mess. Libraries like React attempt to solve this problem in the view layer by removing both asynchrony and direct DOM manipulation. However, managing the state of your data is left up to you. This is where Redux comes in. Following in the footsteps of Flux, CQRS, and Event Sourcing, Redux attempts to make state mutations predictable by imposing certain restrictions on how and when updates can happen. These restrictions are reflected in the three principles of Redux.

同样来自Redux文档:

Core Concepts Redux itself is very simple. Imagine your app's state is described as a plain object. For example, the state of a todo app might look like this: { todos: [{ text: 'Eat food', completed: true }, { text: 'Exercise', completed: false }], visibilityFilter: 'SHOW_COMPLETED' } This object is like a "model" except that there are no setters. This is so that different parts of the code can’t change the state arbitrarily, causing hard-to-reproduce bugs. To change something in the state, you need to dispatch an action. An action is a plain JavaScript object (notice how we don't introduce any magic?) that describes what happened. Here are a few example actions: { type: 'ADD_TODO', text: 'Go to swimming pool' } { type: 'TOGGLE_TODO', index: 1 } { type: 'SET_VISIBILITY_FILTER', filter: 'SHOW_ALL' } Enforcing that every change is described as an action lets us have a clear understanding of what’s going on in the app. If something changed, we know why it changed. Actions are like breadcrumbs of what has happened. Finally, to tie state and actions together, we write a function called a reducer. Again, nothing magic about it — it's just a function that takes state and action as arguments, and returns the next state of the app. It would be hard to write such a function for a big app, so we write smaller functions managing parts of the state: function visibilityFilter(state = 'SHOW_ALL', action) { if (action.type === 'SET_VISIBILITY_FILTER') { return action.filter; } else { return state; } } function todos(state = [], action) { switch (action.type) { case 'ADD_TODO': return state.concat([{ text: action.text, completed: false }]); case 'TOGGLE_TODO': return state.map((todo, index) => action.index === index ? { text: todo.text, completed: !todo.completed } : todo ) default: return state; } } And we write another reducer that manages the complete state of our app by calling those two reducers for the corresponding state keys: function todoApp(state = {}, action) { return { todos: todos(state.todos, action), visibilityFilter: visibilityFilter(state.visibilityFilter, action) }; } This is basically the whole idea of Redux. Note that we haven't used any Redux APIs. It comes with a few utilities to facilitate this pattern, but the main idea is that you describe how your state is updated over time in response to action objects, and 90% of the code you write is just plain JavaScript, with no use of Redux itself, its APIs, or any magic.