javascript - 为什么使用Redux而不是Facebook Flux？ [关闭](Why use Redux over Facebook Flux? [closed])

Question

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

(我已经阅读了这个答案 ， 减少了样板 ，看了几个GitHub示例，甚至尝试了redux（todo apps）。)

As I understand, official redux doc motivations provide pros comparing to traditional MVC architectures.

(据我了解， 官方redux doc动机提供了与传统MVC架构相比的优点。)

BUT it doesn't provide an answer to the question:

(但它没有提供问题的答案：)

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?

(或者问题是在redux方法中遵循的能力/开发工具？)

Maybe scaling?

(也许缩放？)

Or testing?

(还是测试？)

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在flux和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? )

   (处理乐观的更新（ 据我所知，它几乎不取决于第5点。难道在facebook flux中实现它吗？ ）)

2. Rendering on the server ( facebook flux also can do this. Any benefits comparing to redux? )

   (在服务器上渲染（ facebook flux也可以做到这一点。与redux相比有什么好处？ ）)

3. Fetching data before performing route transitions ( Why it can't be achieved in facebook flux? What's the benefits? )

   (在执行路由转换之前获取数据（ 为什么在facebook中无法实现？有什么好处？ ）)

4. Hot reload ( It's possible with React Hot Reload . Why do we need redux? )

   (热重载（ 可以使用React Hot Reload 。为什么我们需要redux？ ）)

5. Undo/Redo functionality

   (撤消/重做功能)

6. Any other points?

   (还有其他一点吗？)

   Like persisting state...

   (像坚持国家一样......)

  ask by VB_ translate from so

Answer 1

Redux author here!

(Redux的作者在这里！)

Redux is not that different from Flux.

(Redux与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使用回调注册的功能组合来削减一些复杂角落。)

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 example handles pagination, but the code for that is awful.

(My Flux + React Router示例处理分页，但代码很糟糕。)

One of the reasons it's awful is that Flux makes it unnatural to reuse functionality across stores.

(可怕的原因之一是Flux使得跨商店重用功能变得不自然。)

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.

(如果两个商店需要处理分页以响应不同的操作，它们或者需要从公共基本存储继承（糟糕！当您使用继承时将自己锁定到特定设计中），或者从内部调用外部定义的函数事件处理程序，需要以某种方式操作Flux存储的私有状态。)

The whole thing is messy (although definitely in the realm of possible).

(整件事情很混乱（虽然绝对是可能的）。)

On the other hand, with Redux pagination is natural thanks to reducer composition.

(另一方面，由于减速器的成分，Redux的分页很自然。)

It's reducers all the way down, so you can write a reducer factory that generates pagination reducers and 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.

(这么简单的关键是因为在Flux中，商店是平的，但在Redux中，reducers可以通过功能组合嵌套，就像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?

(你能想象将Undo / Redo插入一个两行代码的Flux应用程序吗？)

Hardly.

(几乎不。)

With Redux, it is —again, thanks to reducer composition pattern.

(使用Redux，由于减速器组成模式，它是重要的 。)

I need to highlight there's nothing new about it—this is the pattern pioneered and described in detail in Elm Architecture which was itself influenced by Flux.

(我需要强调的是，没有什么新鲜事 - 这是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.

(人们使用Flux在服务器上渲染得很好，但是看到我们有20个Flux库，每个都试图让服务器呈现“更容易”，也许Flux在服务器上有一些粗糙的边缘。)

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.

(事实是Facebook没有做太多的服务器渲染，所以他们并没有非常关注它，并依靠生态系统来使它更容易。)

In traditional Flux, stores are singletons.

(在传统的Flux中，商店是单身人士。)

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 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 Flummox or 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.

(不可否认，Flux框架（不是vanilla Flux）可以解决这些问题，但我发现它们过于复杂。)

For example, Flummox asks you to implement serialize() and deserialize() in your stores .

(例如， Flummox要求您在商店中实现serialize()和deserialize deserialize() 。)

Alt solves this nicer by providing takeSnapshot() that automatically serializes your state in a JSON tree.

(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.

(Redux更进一步： 因为只有一个商店（由许多减速器管理），你不需要任何特殊的API来管理（重新）水合作用。)

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服务器渲染的更多信息。)

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 .

(我实际上并没有打算让Redux成为一个受欢迎的Flux库 - 我写的是因为我正在研究ReactEurope关于时间旅行热重载的讨论 。)

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.

(我有一个主要目标： 可以动态更改减速器代码，甚至可以通过交叉操作“改变过去”，并查看重新计算的状态。)

I haven't seen a single Flux library that is able to do this.

(我还没有看到一个能够做到这一点的Flux库。)

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.

(React Hot Loader也不允许你这样做 - 事实上，如果你编辑Flux商店它会中断，因为它不知道如何处理它们。)

When Redux needs to reload the reducer code, it calls replaceReducer() , and the app runs with the new code.

(当Redux需要重新加载reducer代码时，它会调用<a href="https://stackoom.com/link/aHR0cDovL3JlZHV4LmpzLm9yZy9kb2NzL2FwaS9TdG9yZS5odG1sI3JlcGxhY2VSZWR