Javascript 为什么在 Facebook Flux 上使用 Redux？

Why use Redux over Facebook Flux?

提问by VB_

I've read this answer, reducing boilerplate, looked at few GitHub examples and even tried redux a little bit (todo apps).

我已经阅读了这个答案，减少了样板文件，查看了一些 GitHub 示例，甚至尝试了一些 redux（todo 应用程序）。

As I understand, official redux doc motivationsprovide pros comparing to traditional MVC architectures. BUT it doesn't provide an answer to the question:

据我了解，与传统 MVC 架构相比，官方 redux 文档动机提供了优点。但它没有提供问题的答案：

Why you should use Redux over Facebook Flux?

为什么你应该使用 Redux 而不是 Facebook Flux？

Is that only a question of programming styles: functional vs non-functional? Or the question is in abilities/dev-tools that follow from redux approach? Maybe scaling? Or testing?

这只是编程风格的问题：函数式还是非函数式？或者问题在于 redux 方法遵循的能力/开发工具？也许缩放？还是测试？

Am I right if I say that redux is a flux for people who come from functional languages?

如果我说 redux 是来自函数式语言的人的助推器，我说得对吗？

To answer this question you may compare the complexity of implementation redux's motivation points on flux vs redux.

要回答这个问题，您可以比较实现 redux 在通量与 redux 上的动机点的复杂性。

Here are motivation points from official redux doc motivations:

以下是来自官方 redux doc 动机的动机点：

1. Handling optimistic updates (as I understand, it hardly depends on 5th point. Is it hard to implement it in facebook flux?)
2. Rendering on the server (facebook flux also can do this. Any benefits comparing to redux?)
3. Fetching data before performing route transitions (Why it can't be achieved in facebook flux? What's the benefits?)
4. Hot reload (It's possible with React Hot Reload. Why do we need redux?)
5. Undo/Redo functionality
6. Any other points? Like persisting state...

1. 处理乐观更新（据我所知，这几乎不取决于第 5 点。在 facebook 流量中很难实现它吗？）
2. 在服务器上渲染（Facebook Flux 也可以这样做。与 redux 相比有什么好处？）
3. 在执行路由转换之前获取数据（为什么在 facebook 流量中无法实现？有什么好处？）
4. 热重载（使用React Hot Reload是可能的。为什么我们需要 redux？）
5. 撤消/重做功能
6. 还有其他点吗？就像持久化状态...

回答by Dan Abramov

Redux author here!

Redux 作者在这里！

Redux is not thatdifferent from Flux. Overall it has same architecture, but Redux is able to cut some complexity corners by using functional composition where Flux uses callback registration.

Redux与 Flux没有什么不同。总体而言，它具有相同的架构，但 Redux 能够通过使用 Flux 使用回调注册的功能组合来减少一些复杂性。

There is not a fundamental difference in Redux, but I find it makes certain abstractions easier, or at least possible to implement, that would be hard or impossible to implement in Flux.

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

Reducer Composition

减速机组成

Take, for example, pagination. My Flux + React Router examplehandles 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).

以分页为例。我的Flux + React Router 示例处理分页，但代码很糟糕。糟糕的原因之一是Flux 使得跨商店重用功能变得不自然。如果两个 store 需要处理分页以响应不同的操作，它们要么需要从一个公共基础 store 继承（糟糕！当你使用继承时，你将自己锁定在一个特定的设计中），或者从内部调用一个外部定义的函数事件处理程序，它需要以某种方式对 Flux 存储的私有状态进行操作。整个事情很混乱（尽管绝对是在可能的范围内）。

On the other hand, with Redux pagination is natural thanks to reducer composition. It's reducers all the way down, so you can write a reducer factory that generates pagination reducersand then use it in your reducer tree. The key to why it's so easy is because in Flux, stores are flat, but in Redux, reducers can be nested via functional composition, just like React components can be nested.

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

This pattern also enables wonderful features like no-user-code 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 Architecturewhich was itself influenced by Flux.

这种模式还支持无用户代码undo/redo等精彩功能。您能想象将 Undo/Redo 插入 Flux 应用程序是两行代码吗？几乎不。使用 Redux，再次感谢 reducer 组合模式。我需要强调的是，它并没有什么新东西——这是Elm Architecture 中开创和详细描述的模式，它本身受 Flux 的影响。

Server Rendering

服务器渲染

People have been rendering on the server fine with Flux, but seeing that we have 20 Flux libraries each attempting to make server rendering “easier”, perhaps Flux has some rough edges on the server. The truth is Facebook doesn't do much server rendering, so they haven't been very concerned about it, and rely on the ecosystem to make it easier.

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

In traditional Flux, stores are singletons. This means it's hard to separate the data for different requests on the server. Not impossible, but hard. This is why most Flux libraries (as well as the new Flux Utils) now suggest you use classes instead of singletons, so you can instantiate stores per request.

在传统的 Flux 中，商店是单身人士。这意味着很难将服务器上不同请求的数据分开。不是不可能，但很难。这就是为什么大多数 Flux 库（以及新的Flux Utils）现在建议您使用类而不是单例，以便您可以根据请求实例化存储。

There are still the following problems that you need to solve in Flux (either yourself or with the help of your favorite Flux library such as Flummoxor Alt):

您仍然需要在 Flux 中解决以下问题（您自己或借助您最喜欢的 Flux 库，例如Flummox或Alt）：

• If stores are classes, how do I create and destroy them with dispatcher per request? When do I register stores?
• How do I hydrate the data from the stores and later rehydrate it on the client? Do I need to implement special methods for this?

• 如果商店是类，我如何根据请求使用调度程序创建和销毁它们？我什么时候注册商店？
• 我如何将存储中的数据水化，然后在客户端上将其重新水化？我需要为此实现特殊方法吗？

Admittedly Flux frameworks (not vanilla Flux) have solutions to these problems, but I find them overcomplicated. For example, Flummox asks you to implement serialize()and deserialize()in your stores. Alt solves this nicer by providing takeSnapshot()that automatically serializes your state in a JSON tree.

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

Redux just goes further: since there is just a single store (managed by many reducers), you don't need any special API to manage the (re)hydration.You don't need to “flush” or “hydrate” stores—there's just a single store, and you can read its current state, or create a new store with a new state. Each request gets a separate store instance. Read more about server rendering with Redux.

Redux 更进一步：因为只有一个存储（由许多减速器管理），您不需要任何特殊的 API 来管理（重新）水化。你不需要“刷新”或“水合”存储——只有一个存储，你可以读取它的当前状态，或者用一个新的状态创建一个新的存储。每个请求都会获得一个单独的商店实例。阅读有关使用 Redux 进行服务器渲染的更多信息。

Again, this is a case of something possible both in Flux and Redux, but Flux libraries solve this problem by introducing a ton of API and conventions, and Redux doesn't even have to solve it because it doesn't have that problem in the first place thanks to conceptual simplicity.

同样，这是在 Flux 和 Redux 中都有可能发生的情况，但是 Flux 库通过引入大量 API 和约定来解决这个问题，而 Redux 甚至不必解决它，因为它在首先要感谢概念上的简单性。

Developer Experience

开发者体验

I didn't actually intend Redux to become a popular Flux library—I wrote it as I was working on my ReactEurope talk on hot reloading with time travel. I had one main objective: make it possible to change reducer code on the fly or even “change the past” by crossing out actions, and see the state being recalculated.

我实际上并不打算将 Redux 变成一个流行的 Flux 库——我写它的时候我正在做我的ReactEurope 演讲，关于热重载和时间旅行。我有一个主要目标：通过删除动作来动态更改减速器代码甚至“改变过去”，并查看重新计算的状态成为可能。

I haven't seen a single Flux library that is able to do this. React Hot Loader also doesn't let you do this—in fact it breaks if you edit Flux stores because it doesn't know what to do with them.

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

When Redux needs to reload the reducer code, it calls replaceReducer(), and the app runs with the new code. In Flux, data and functions are entangled in Flux stores, so you can't “just replace the functions”. Moreover, you'd have to somehow re-register the new versions with the Dispatcher—something Redux doesn't even have.

当 Redux 需要重新加载 reducer 代码时，它会调用replaceReducer()，然后应用程序使用新代码运行。在 Flux 中，数据和函数纠缠在 Flux 存储中，所以你不能“只是替换函数”。此外，您必须以某种方式向 Dispatcher 重新注册新版本 — Redux 甚至没有。

Ecosystem

生态系统

Redux has a 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, etc, in mind. Not all of these will turn out to be useful, but it's nice to have access to a set of tools that can be easily combined to work together.

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

Simplicity

简单

Redux preserves all the benefits of Flux (recording and replaying of actions, unidirectional data flow, dependent mutations) and adds new benefits (easy undo-redo, hot reloading) without introducing Dispatcher and store registration.

Redux 保留了 Flux 的所有优点（记录和重放动作、单向数据流、依赖突变）并增加了新的优点（容易撤销重做、热重载），而没有引入 Dispatcher 和存储注册。

Keeping it simple is important because it keeps you sane while you implement higher-level abstractions.

保持简单很重要，因为它可以让您在实现更高级别的抽象时保持理智。

Unlike most Flux libraries, Redux API surface is tiny. If you remove the developer warnings, comments, and sanity checks, it's 99 lines. There is no tricky async code to debug.

与大多数 Flux 库不同，Redux API 表面很小。如果您删除开发人员警告、评论和健全性检查，则为99 行。没有需要调试的棘手异步代码。

You can actually read it and understand all of Redux.

您实际上可以阅读它并理解所有 Redux。

---

---

See also my answer on downsides of using Redux compared to Flux.

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

回答by Alireza

In Quora, somebody says:

在 Quora，有人说：

First of all, it is totally possible to write apps with React without Flux.

首先，完全可以在没有 Flux 的情况下使用 React 编写应用程序。

Also this visual diagramwhich I've created to show a quick view of both, probably a quick answer for the people who don't want to read the whole explanation:

还有这个我创建的可视化图表，用于显示两者的快速视图，对于不想阅读整个解释的人来说可能是一个快速答案：

But if you still interested knowing more, read on.

但是，如果您仍然有兴趣了解更多信息，请继续阅读。

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.

我相信你应该从纯 React 开始，然后学习 Redux 和 Flux。在你对 React 有了一些真正的体验后，你会看到 Redux 是否对你有帮助。

也许你会觉得 Redux 正是你的应用程序，也许你会发现，Redux 正试图解决一个你并没有真正遇到的问题。

如果您直接从 Redux 开始，与没有 Redux 相比，您最终可能会得到过度设计的代码、更难维护的代码以及更多的错误。

From Redux docs:

来自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.

动机
随着 JavaScript 单页应用程序的需求变得越来越复杂，我们的代码必须管理比以往更多的状态。此状态可以包括服务器响应和缓存数据，以及尚未保存到服务器的本地创建数据。UI 状态的复杂性也在增加，因为我们需要管理活动路由、选定的选项卡、微调器、分页控件等。

管理这种不断变化的状态很困难。如果一个模型可以更新另一个模型，那么一个视图可以更新一个模型，该模型更新另一个模型，这反过来可能会导致另一个视图更新。在某些时候，您不再了解应用程序中发生了什么，因为您无法控制其状态的时间、原因和方式。当系统不透明且不确定时，很难重现错误或添加新功能。

好像这还不够糟糕，请考虑新需求在前端产品开发中变得普遍。作为开发人员，我们需要处理乐观更新、服务器端渲染、在执行路由转换之前获取数据等。我们发现自己正试图管理我们以前从未处理过的复杂性，我们不可避免地会问一个问题：是时候放弃了吗？答案是不。

这种复杂性很难处理，因为我们混合了两个人类思维很难推理的概念：变异和异步。我称它们为曼妥思和可乐。两者分开时都很棒，但它们在一起会造成混乱。像 React 这样的库试图通过移除异步和直接 DOM 操作来解决视图层中的这个问题。但是，管理数据状态取决于您。这就是 Redux 的用武之地。

跟随 Flux、CQRS 和事件溯源的脚步，Redux 试图通过对更新发生的方式和时间施加某些限制来使状态变化可预测。这些限制体现在 Redux 的三个原则中。

Also from Redux docs:

同样来自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.

核心概念
Redux 本身非常简单。

想象一下，您的应用程序的状态被描述为一个普通对象。例如，todo 应用程序的状态可能如下所示：

{
  todos: [{
    text: 'Eat food',
    completed: true
  }, {
    text: 'Exercise',
    completed: false
  }],
  visibilityFilter: 'SHOW_COMPLETED'
}

这个对象就像一个“模型”，只是没有设置器。这是为了代码的不同部分不能随意改变状态，导致难以重现的错误。

要更改状态中的某些内容，您需要分派一个动作。一个动作是一个简单的 JavaScript 对象（注意我们是如何不引入任何魔法的？），它描述了发生的事情。以下是一些示例操作：

{ type: 'ADD_TODO', text: 'Go to swimming pool' }
{ type: 'TOGGLE_TODO', index: 1 }
{ type: 'SET_VISIBILITY_FILTER', filter: 'SHOW_ALL' }

强制将每个更改都描述为一个操作，这样我们就可以清楚地了解应用程序中发生的事情。如果有什么改变了，我们就知道它为什么改变了。行动就像已经发生的事情的面包屑。最后，为了将状态和动作联系在一起，我们编写了一个名为 reducer 的函数。同样，它没有什么神奇之处——它只是一个将状态和动作作为参数并返回应用程序的下一个状态的函数。为大型应用程序编写这样的函数会很困难，因此我们编写了管理状态部分的较小函数：

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;
  }
}

我们编写了另一个 reducer，它通过为相应的状态键调用这两个 reducer 来管理我们应用程序的完整状态：

function todoApp(state = {}, action) {
  return {
    todos: todos(state.todos, action),
    visibilityFilter: visibilityFilter(state.visibilityFilter, action)
  };
}

这基本上就是 Redux 的全部思想。请注意，我们尚未使用任何 Redux API。它附带了一些实用程序来促进这种模式，但主要思想是你描述你的状态如何随着时间的推移更新以响应动作对象，并且你编写的 90% 的代码只是普通的 JavaScript，没有使用 Redux本身、它的 API 或任何魔法。

回答by Hal

You might be best starting with reading this post by Dan Abramov where he discusses various implementations of Flux and their trade-offs at the time he was writing redux: The Evolution of Flux Frameworks

您可能最好先阅读 Dan Abramov 的这篇文章，他在其中讨论了 Flux 的各种实现及其在编写 redux 时的权衡： Flux 框架的演变

Secondly that motivations page you link to does not really discuss the motivations of Redux so much as the motivations behind Flux (and React). The Three Principlesis more Redux specific though still does not deal with the implementation differences from the standard Flux architecture.

其次，您链接到的动机页面并没有真正讨论 Redux 的动机，而是讨论 Flux（和 React）背后的动机。该三原则是更终极版特定但仍无法应付来自标准通量架构的实现差异。

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.

基本上，Flux 有多个 store 来计算状态变化以响应 UI/API 与组件的交互，并将这些变化作为组件可以订阅的事件进行广播。在 Redux 中，每个组件都只订阅一个 store。IMO 感觉至少 Redux 通过统一（或减少，如 Redux 所说）返回组件的数据流来进一步简化和统一数据流 - 而 Flux 专注于统一数据流的另一侧 - 查看模型。

回答by Guy Nesher

I'm an early adopter and implemented a mid-large single page application using the Facebook Flux library.

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

As I'm a little late to the conversation I'll just point out that despite my best hopes Facebook seem to consider their Flux implementation to be a proof of concept and it has never received the attention it deserves.

由于我的谈话有点晚了，我只想指出，尽管我抱有最大的希望，但 Facebook 似乎认为他们的 Flux 实现是概念证明，但它从未得到应有的关注。

I'd encourage you to play with it, as it exposes more of the inner working of the Flux architecture which is quite educational, but at the same time it does not provide many of the benefits that libraries like Redux provide (which aren't that important for small projects, but become very valuable for bigger ones).

我鼓励你使用它，因为它揭示了 Flux 架构的更多内部工作，这很有教育意义，但同时它没有提供像 Redux 这样的库提供的许​​多好处（这些好处不是这对小项目很重要，但对大项目非常有价值）。

We have decided that moving forward we will be moving to Redux and I suggest you do the same ;)

我们决定继续前进，我们将转向 Redux，我建议您也这样做；)

回答by Prathap Kudupu

Here is the simple explanation of Redux over Flux. Redux does not have a dispatcher.It relies on pure functions called reducers. It does not need a dispatcher. Each actions are handled by one or more reducers to update the single store. Since data is immutable, reducers returns a new updated state that updates the store

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

For more information Flux vs Redux

有关Flux 与 Redux 的更多信息

回答by Krasimir

I worked quite a long time with Flux and now quite a long time using Redux. As Dan pointed out both architectures are not so different. The thing is that Redux makes the things simpler and cleaner. It teaches you a couple of things on top of Flux. Like for example Flux is a perfect example of one-direction data flow. Separation of concerns where we have data, its manipulations and view layer separated. In Redux we have the same things but we also learn about immutability and pure functions.

我在 Flux 上工作了很长时间，现在使用 Redux 也有很长时间了。正如丹指出的那样，两种架构都没有太大不同。问题是 Redux 使事情变得更简单、更干净。它教你一些关于 Flux 的事情。例如 Flux 是单向数据流的完美示例。在我们拥有数据的地方分离关注点，其操作和视图层分离。在 Redux 中，我们有同样的东西，但我们也学习了不变性和纯函数。

回答by vanderwyst

From a new react/redux adopter migrating from (a few years of) ExtJS in mid-2018:

来自 2018 年中期从（几年的）ExtJS 迁移的新 react/redux 采用者：

After sliding backward down the redux learning curve I had the same question and thought pure flux would be simpler like OP.

在沿着 redux 学习曲线向后滑动后，我遇到了同样的问题，并认为纯通量会像 OP 一样简单。

I soon saw the benefits of redux over flux as noted in the answers above, and was working it into my first app.

我很快就看到了上面的答案中提到的 redux 优于flux 的好处，并且正在将它应用到我的第一个应用程序中。

While getting a grip on the boiler plate again, I tried out a few of the otherstate management libs, the best I found was rematch.

在再次掌握样板的同时，我尝试了其他一些状态管理库，我发现最好的是rematch。

It was muchmore intuitive then vanilla redux, it cuts out 90% of the boilerplate and cut out 75% of the time I was spending on redux (something I think a library should be doing), I was able to get a couple enterprise apps going right away.

它比普通的redux 直观得多，它减少了 90% 的样板文件并减少了我在 redux 上花费的 75% 的时间（我认为图书馆应该做的事情），我能够获得几个企业应用程序马上去。

It also runs with the same redux tooling. This is a good articlethat covers some of the benefits.

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

So for anyone else who arrived to this SO post searching "simpler redux", I recommend trying it out as a simple alternative to redux with all the benefits and 1/4 of the boilerplate.

因此，对于到此 SO 帖子搜索“更简单的 redux”的其他任何人，我建议尝试将其作为 redux 的简单替代品，它具有所有优点和 1/4 的样板。

回答by yairniz

According to this article: https://medium.freecodecamp.org/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075

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

You better use MobX to manage the data in your app to get better performance, not Redux.

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