为什么使用 Redux 而不是 Facebook Flux？
Why use Redux over Facebook Flux?
我读过 , reducing boilerplate，看过几个 GitHub 示例，甚至尝试了一点 redux（todo 应用程序）。
据我了解，official redux doc motivations 与传统 MVC 架构相比具有优势。但它没有提供问题的答案：
为什么你应该使用 Redux 而不是 Facebook Flux？
这只是编程风格的问题：函数式还是非函数式？或者问题出在 redux 方法的 abilities/dev-tools 中？也许缩放？还是测试？
如果我说 redux 对于来自函数式语言的人来说是一种流动性，我是对的吗？
要回答这个问题，您可以比较 redux 在 flux 和 redux 上的实现动机点的复杂性。
以下是 official redux doc motivations 的激励点：
- 处理乐观更新（据我了解，它几乎不依赖于第5点。在facebook flux中很难实现吗？）
- 在服务器上渲染（facebook flux 也可以做到这一点。与 redux 相比有什么好处吗？）
- 在执行路由转换之前获取数据（为什么在facebook flux中无法实现？有什么好处？）
- 热重载（React Hot Reload可以实现。为什么我们需要 redux？）
- Undo/Redo 功能
- 还有什么要点？喜欢持久状态...
您最好从阅读 Dan Abramov 的 post 开始，他在其中讨论了 Flux 的各种实现及其在编写 redux 时的权衡：
The Evolution of Flux Frameworks
其次，你 link 的动机页面并没有真正讨论 Redux 的动机，而是讨论了 Flux（和 React）背后的动机。 Three Principles 更具体地说明了 Redux，但仍然没有处理与标准 Flux 架构的实现差异。
基本上，Flux 有多个存储计算状态变化以响应与组件的 UI/API 交互，并将这些变化作为组件可以订阅的事件广播。在 Redux 中，每个组件只订阅一个商店。 IMO 至少感觉 Redux 通过统一（或减少，如 Redux 所说）返回组件的数据流来进一步简化和统一数据流——而 Flux 专注于统一数据流的另一端——查看型号。
这里是 Redux 作者！
Redux 与 Flux 没有什么不同。总体而言，它具有相同的架构，但 Redux 能够通过使用功能组合来减少一些复杂性，而 Flux 使用回调注册。
在 Redux 中没有根本的区别，但我发现它使某些抽象更容易，或者至少可以实现，而在 Flux 中很难或不可能实现。
减速机组成
以分页为例。我的 Flux + React Router example 处理分页，但它的代码很糟糕。它很糟糕的原因之一是 Flux 使得跨商店重用功能变得不自然。 如果两个商店需要处理分页以响应不同的操作，它们要么需要从公共基础继承存储（糟糕！当你使用继承时，你将自己锁定在一个特定的设计中），或者从事件处理程序中调用一个外部定义的函数，这将需要以某种方式对 Flux 存储的私有状态进行操作。整个事情很乱（尽管绝对在可能的范围内）。
另一方面，由于 reducer 的组合，Redux 的分页是自然的。它一直是减速器，所以你可以写一个reducer factory that generates pagination reducers and then use it in your reducer tree。之所以如此简单的关键是因为 在 Flux 中，store 是扁平的，而在 Redux 中，reducer 可以通过函数组合来嵌套，就像 React 组件可以嵌套一样。
此模式还启用了一些很棒的功能，例如无用户代码 undo/redo. Can you imagine plugging Undo/Redo into a Flux app being two lines of code? Hardly. With Redux, it is—again, thanks to reducer composition pattern. I need to highlight there's nothing new about it—this is the pattern pioneered and described in detail in Elm Architecture，它本身受 Flux 的影响。
服务器渲染
人们一直在使用 Flux 在服务器上进行良好的渲染，但是看到我们有 20 个 Flux 库，每个库都试图使服务器渲染“更容易”，也许 Flux 在服务器上有一些粗糙的边缘。事实上，Facebook 并没有做太多的服务器渲染，所以他们一直不太关心它，并依靠生态系统让它变得更容易。
在传统的 Flux 中，商店是单身人士。这意味着很难分离服务器上不同请求的数据。不是不可能，而是很难。这就是为什么大多数 Flux 库（以及新的 Flux Utils）现在建议您使用 类 而不是单例，这样您就可以根据请求实例化存储。
在 Flux 中还有以下问题需要您解决（无论是您自己还是借助您最喜欢的 Flux 库，例如 Flummox or Alt）：
- 如果商店是 类，我如何根据请求使用调度程序创建和销毁它们？我什么时候注册商店？
- 如何对存储中的数据进行水合，然后再在客户端对其进行水合？我需要为此实现特殊方法吗？
诚然，Flux 框架（不是 vanilla Flux）可以解决这些问题，但我发现它们过于复杂。例如，Flummox asks you to implement serialize() and deserialize() in your stores. Alt solves this nicer by providing takeSnapshot() 会在 JSON 树中自动序列化您的状态。
Redux 更进一步：因为只有一个存储（由许多 reducer 管理），您不需要任何特殊的 API 来管理（重新）水化。 您不需要“冲洗”或“水化”商店——只有一个商店，您可以读取它的当前状态，或创建一个具有新状态的新商店。每个请求都会获得一个单独的商店实例。 Read more about server rendering with Redux.
同样，这在 Flux 和 Redux 中都是可能的，但是 Flux 库通过引入大量 API 和约定来解决这个问题，而 Redux 甚至不必解决它，因为由于概念简单，它首先没有这个问题。
开发者经验
我实际上并没有打算让 Redux 成为一个流行的 Flux 库——我在写我的 ReactEurope talk on hot reloading with time travel 的时候就写了它。我有一个主要的 objective：可以动态更改 reducer 代码，甚至可以通过划掉操作来“改变过去”，并查看正在重新计算的状态。
我还没有看到一个 Flux 库能够做到这一点。 React Hot Loader 也不允许您这样做——事实上，如果您编辑 Flux 存储，它就会中断，因为它不知道如何处理它们。
当 Redux 需要重新加载 reducer 代码时，它会调用 replaceReducer()，应用程序将使用新代码运行。在 Flux 中，数据和函数纠缠在 Flux 存储中，因此您不能“只替换函数”。此外，您必须以某种方式向 Dispatcher 重新注册新版本——这是 Redux 甚至没有的。
生态系统
Redux 有一个 rich and fast-growing ecosystem. This is because it provides a few extension points such as middleware. It was designed with use cases such as logging, support for Promises, Observables, routing, immutability dev checks, persistence，等等。并非所有这些都会有用，但很高兴能够访问一组可以轻松组合在一起工作的工具。
简单
Redux 保留了 Flux 的所有优点（动作的记录和回放、单向数据流、依赖突变）并增加了新的优点（轻松撤消重做、热重载），而无需引入 Dispatcher 和存储注册。
保持简单很重要，因为它可以让您在实现更高级别的抽象时保持理智。
与大多数 Flux 库不同，Redux API 表面很小。如果您删除开发人员警告、评论和健全性检查，它就是 99 lines。没有棘手的异步代码可以调试。
你可以真正阅读它并理解所有 Redux。
另见 。
我是早期采用者并使用 Facebook Flux 库实现了一个 mid-large 单页应用程序。
由于我来晚了一点，我只想指出，尽管我满怀希望，但 Facebook 似乎将他们的 Flux 实施视为概念验证，但它从未得到应有的关注。
我鼓励您尝试使用它，因为它揭示了 Flux 架构的更多内部工作原理，这很有教育意义，但与此同时，它并没有提供像 Redux 这样的库所提供的许多好处（这对于小项目来说不是那么重要，但对于大项目来说非常有价值）。
我们已经决定，今后我们将转向 Redux，我建议您也这样做 ;)
First of all, it is totally possible to write apps with React without
Flux.
还有这个可视化图表，我创建它是为了快速查看两者，对于不想阅读整个解释的人来说可能是一个快速的答案：
但如果您仍然有兴趣了解更多信息，请继续阅读。
I believe you should start with pure React, then learn Redux and Flux.
After you will have some REAL experience with React, you will see
whether Redux is helpful for you or not.
Maybe you will feel that Redux is exactly for your app and maybe you
will find out, that Redux is trying to solve a problem you are not
really experiencing.
If you start directly with Redux, you may end up with over-engineered
code, code harder to maintain and with even more bugs and than without
Redux.
来自 Redux docs:
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 docs：
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.
这里简单解释一下Redux over Flux。
Redux 没有 dispatcher.It 依赖称为 reducer 的纯函数。它不需要调度程序。每个动作都由一个或多个 reducer 处理以更新单个存储。由于数据是不可变的，reducers returns 一个新的更新状态更新了 store
更多信息Flux vs Redux
我用 Flux 工作了很长时间，现在用 Redux 也用了很长时间。正如 Dan 所指出的，这两种架构并没有太大的不同。关键是 Redux 让事情变得更简单、更干净。它会教您一些关于 Flux 的知识。例如 Flux 是单向数据流的完美示例。分离我们拥有数据的关注点，它的操作和视图层是分离的。在 Redux 中我们有相同的东西，但我们还学习了不变性和纯函数。
来自 2018 年年中从（几年）ExtJS 迁移过来的新 react/redux 采纳者：
在 redux 学习曲线向后滑动后，我有同样的问题，认为纯 flux 会像 OP 一样简单。
我很快就看到了上面答案中提到的 redux 相对于 flux 的好处，并将其应用到我的第一个应用程序中。
在再次掌握样板的同时，我尝试了一些 other 状态管理库，我发现最好的是 rematch。
它比 vanilla redux 更直观，它减少了 90% 的样板文件，减少了我花在 redux 上的时间的 75%（我认为这是一个库应该做的），我能够立即运行几个企业应用程序。
它也使用相同的 redux 工具运行。这是一个涵盖了一些好处的good article。
因此，对于到达此 SO post 搜索 "simpler redux" 的任何其他人，我建议将其作为 redux 的简单替代品来尝试，它具有所有优点和 1/4 的样板文件。
您最好使用 MobX 来管理应用中的数据以获得更好的性能，而不是 Redux。
我读过
据我了解，official redux doc motivations 与传统 MVC 架构相比具有优势。但它没有提供问题的答案：
为什么你应该使用 Redux 而不是 Facebook Flux？
这只是编程风格的问题：函数式还是非函数式？或者问题出在 redux 方法的 abilities/dev-tools 中？也许缩放？还是测试？
如果我说 redux 对于来自函数式语言的人来说是一种流动性，我是对的吗？
要回答这个问题，您可以比较 redux 在 flux 和 redux 上的实现动机点的复杂性。
以下是 official redux doc motivations 的激励点：
- 处理乐观更新（据我了解，它几乎不依赖于第5点。在facebook flux中很难实现吗？）
- 在服务器上渲染（facebook flux 也可以做到这一点。与 redux 相比有什么好处吗？）
- 在执行路由转换之前获取数据（为什么在facebook flux中无法实现？有什么好处？）
- 热重载（React Hot Reload可以实现。为什么我们需要 redux？）
- Undo/Redo 功能
- 还有什么要点？喜欢持久状态...
您最好从阅读 Dan Abramov 的 post 开始，他在其中讨论了 Flux 的各种实现及其在编写 redux 时的权衡： The Evolution of Flux Frameworks
其次，你 link 的动机页面并没有真正讨论 Redux 的动机，而是讨论了 Flux（和 React）背后的动机。 Three Principles 更具体地说明了 Redux，但仍然没有处理与标准 Flux 架构的实现差异。
基本上，Flux 有多个存储计算状态变化以响应与组件的 UI/API 交互，并将这些变化作为组件可以订阅的事件广播。在 Redux 中，每个组件只订阅一个商店。 IMO 至少感觉 Redux 通过统一（或减少，如 Redux 所说）返回组件的数据流来进一步简化和统一数据流——而 Flux 专注于统一数据流的另一端——查看型号。
这里是 Redux 作者！
Redux 与 Flux 没有什么不同。总体而言，它具有相同的架构，但 Redux 能够通过使用功能组合来减少一些复杂性，而 Flux 使用回调注册。
在 Redux 中没有根本的区别，但我发现它使某些抽象更容易，或者至少可以实现，而在 Flux 中很难或不可能实现。
减速机组成
以分页为例。我的 Flux + React Router example 处理分页，但它的代码很糟糕。它很糟糕的原因之一是 Flux 使得跨商店重用功能变得不自然。 如果两个商店需要处理分页以响应不同的操作，它们要么需要从公共基础继承存储（糟糕！当你使用继承时，你将自己锁定在一个特定的设计中），或者从事件处理程序中调用一个外部定义的函数，这将需要以某种方式对 Flux 存储的私有状态进行操作。整个事情很乱（尽管绝对在可能的范围内）。
另一方面，由于 reducer 的组合，Redux 的分页是自然的。它一直是减速器，所以你可以写一个reducer factory that generates pagination reducers and then use it in your reducer tree。之所以如此简单的关键是因为 在 Flux 中，store 是扁平的，而在 Redux 中，reducer 可以通过函数组合来嵌套，就像 React 组件可以嵌套一样。
此模式还启用了一些很棒的功能，例如无用户代码 undo/redo. Can you imagine plugging Undo/Redo into a Flux app being two lines of code? Hardly. With Redux, it is—again, thanks to reducer composition pattern. I need to highlight there's nothing new about it—this is the pattern pioneered and described in detail in Elm Architecture，它本身受 Flux 的影响。
服务器渲染
人们一直在使用 Flux 在服务器上进行良好的渲染，但是看到我们有 20 个 Flux 库，每个库都试图使服务器渲染“更容易”，也许 Flux 在服务器上有一些粗糙的边缘。事实上，Facebook 并没有做太多的服务器渲染，所以他们一直不太关心它，并依靠生态系统让它变得更容易。
在传统的 Flux 中，商店是单身人士。这意味着很难分离服务器上不同请求的数据。不是不可能，而是很难。这就是为什么大多数 Flux 库（以及新的 Flux Utils）现在建议您使用 类 而不是单例，这样您就可以根据请求实例化存储。
在 Flux 中还有以下问题需要您解决（无论是您自己还是借助您最喜欢的 Flux 库，例如 Flummox or Alt）：
- 如果商店是 类，我如何根据请求使用调度程序创建和销毁它们？我什么时候注册商店？
- 如何对存储中的数据进行水合，然后再在客户端对其进行水合？我需要为此实现特殊方法吗？
诚然，Flux 框架（不是 vanilla Flux）可以解决这些问题，但我发现它们过于复杂。例如，Flummox asks you to implement serialize() and deserialize() in your stores. Alt solves this nicer by providing takeSnapshot() 会在 JSON 树中自动序列化您的状态。
Redux 更进一步：因为只有一个存储（由许多 reducer 管理），您不需要任何特殊的 API 来管理（重新）水化。 您不需要“冲洗”或“水化”商店——只有一个商店，您可以读取它的当前状态，或创建一个具有新状态的新商店。每个请求都会获得一个单独的商店实例。 Read more about server rendering with Redux.
同样，这在 Flux 和 Redux 中都是可能的，但是 Flux 库通过引入大量 API 和约定来解决这个问题，而 Redux 甚至不必解决它，因为由于概念简单，它首先没有这个问题。
开发者经验
我实际上并没有打算让 Redux 成为一个流行的 Flux 库——我在写我的 ReactEurope talk on hot reloading with time travel 的时候就写了它。我有一个主要的 objective：可以动态更改 reducer 代码，甚至可以通过划掉操作来“改变过去”，并查看正在重新计算的状态。
我还没有看到一个 Flux 库能够做到这一点。 React Hot Loader 也不允许您这样做——事实上，如果您编辑 Flux 存储，它就会中断，因为它不知道如何处理它们。
当 Redux 需要重新加载 reducer 代码时，它会调用 replaceReducer()，应用程序将使用新代码运行。在 Flux 中，数据和函数纠缠在 Flux 存储中，因此您不能“只替换函数”。此外，您必须以某种方式向 Dispatcher 重新注册新版本——这是 Redux 甚至没有的。
生态系统
Redux 有一个 rich and fast-growing ecosystem. This is because it provides a few extension points such as middleware. It was designed with use cases such as logging, support for Promises, Observables, routing, immutability dev checks, persistence，等等。并非所有这些都会有用，但很高兴能够访问一组可以轻松组合在一起工作的工具。
简单
Redux 保留了 Flux 的所有优点（动作的记录和回放、单向数据流、依赖突变）并增加了新的优点（轻松撤消重做、热重载），而无需引入 Dispatcher 和存储注册。
保持简单很重要，因为它可以让您在实现更高级别的抽象时保持理智。
与大多数 Flux 库不同，Redux API 表面很小。如果您删除开发人员警告、评论和健全性检查，它就是 99 lines。没有棘手的异步代码可以调试。
你可以真正阅读它并理解所有 Redux。
另见
我是早期采用者并使用 Facebook Flux 库实现了一个 mid-large 单页应用程序。
由于我来晚了一点，我只想指出，尽管我满怀希望，但 Facebook 似乎将他们的 Flux 实施视为概念验证，但它从未得到应有的关注。
我鼓励您尝试使用它，因为它揭示了 Flux 架构的更多内部工作原理，这很有教育意义，但与此同时，它并没有提供像 Redux 这样的库所提供的许多好处（这对于小项目来说不是那么重要，但对于大项目来说非常有价值）。
我们已经决定，今后我们将转向 Redux，我建议您也这样做 ;)
First of all, it is totally possible to write apps with React without Flux.
还有这个可视化图表，我创建它是为了快速查看两者，对于不想阅读整个解释的人来说可能是一个快速的答案：
但如果您仍然有兴趣了解更多信息，请继续阅读。
I believe you should start with pure React, then learn Redux and Flux. After you will have some REAL experience with React, you will see whether Redux is helpful for you or not.
Maybe you will feel that Redux is exactly for your app and maybe you will find out, that Redux is trying to solve a problem you are not really experiencing.
If you start directly with Redux, you may end up with over-engineered code, code harder to maintain and with even more bugs and than without Redux.
来自 Redux docs:
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 docs：
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.
这里简单解释一下Redux over Flux。
Redux 没有 dispatcher.It 依赖称为 reducer 的纯函数。它不需要调度程序。每个动作都由一个或多个 reducer 处理以更新单个存储。由于数据是不可变的，reducers returns 一个新的更新状态更新了 store
更多信息Flux vs Redux
我用 Flux 工作了很长时间，现在用 Redux 也用了很长时间。正如 Dan 所指出的，这两种架构并没有太大的不同。关键是 Redux 让事情变得更简单、更干净。它会教您一些关于 Flux 的知识。例如 Flux 是单向数据流的完美示例。分离我们拥有数据的关注点，它的操作和视图层是分离的。在 Redux 中我们有相同的东西，但我们还学习了不变性和纯函数。
来自 2018 年年中从（几年）ExtJS 迁移过来的新 react/redux 采纳者：
在 redux 学习曲线向后滑动后，我有同样的问题，认为纯 flux 会像 OP 一样简单。
我很快就看到了上面答案中提到的 redux 相对于 flux 的好处，并将其应用到我的第一个应用程序中。
在再次掌握样板的同时，我尝试了一些 other 状态管理库，我发现最好的是 rematch。
它比 vanilla redux 更直观，它减少了 90% 的样板文件，减少了我花在 redux 上的时间的 75%（我认为这是一个库应该做的），我能够立即运行几个企业应用程序。
它也使用相同的 redux 工具运行。这是一个涵盖了一些好处的good article。
因此，对于到达此 SO post 搜索 "simpler redux" 的任何其他人，我建议将其作为 redux 的简单替代品来尝试，它具有所有优点和 1/4 的样板文件。
您最好使用 MobX 来管理应用中的数据以获得更好的性能，而不是 Redux。