javascript - 为什么在 Facebook Flux 上使用 Redux？

Question

关闭。这个问题是opinion-based .它目前不接受答案。




2年前关闭。










锁定。这个问题及其答案是locked因为这个问题是题外话，但具有历史意义。它目前不接受新的答案或互动。








我已阅读 this answer , reducing boilerplate ，看了几个 GitHub 示例，甚至尝试了一点 redux(todo 应用程序)。

据我了解，official redux doc motivations提供与传统 MVC 架构相比的优点。但它没有提供问题的答案:

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

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

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

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

以下是来自 official redux doc motivations 的动机点:

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

在服务器上渲染(Facebook Flux 也可以这样做。与 redux 相比有什么好处？)

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

热重载(使用 React Hot Reload 是可能的。为什么我们需要 redux？)

撤消/重做功能

还有其他点吗？像持久化状态...

Answer 1

Redux 作者在这里!

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

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

reducer 组成

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

另一方面，由于 reducer 组合，Redux 分页是自然的。它一直是 reducer ，所以你可以写一个 reducer factory that generates pagination reducers然后 use it in your reducer tree .之所以如此简单，关键在于 在 Flux 中，stores 是扁平的，但在 Redux 中，reducer 可以通过函数组合嵌套，就像 React 组件可以嵌套一样。

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

服务器渲染

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

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

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

如果商店是类，我如何根据请求使用调度程序创建和销毁它们？我什么时候注册商店？

我如何将存储中的数据水化，然后在客户端上将其重新水化？我需要为此实现特殊方法吗？

诚然，Flux 框架(不是普通的 Flux)可以解决这些问题，但我发现它们过于复杂。例如， Flummox asks you to implement serialize() and deserialize() in your stores . Alt 通过提供 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 上工作时写的。 .我有一个主要目标: 使动态更改 reducer 代码成为可能，甚至可以通过删除 Action 来“改变过去”，并查看重新计算的状态。



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

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

生态系统

Redux 有一个 rich and fast-growing ecosystem .这是因为它提供了一些扩展点，例如 middleware .它是为用例而设计的，例如 logging ，支持 Promises , Observables , routing , immutability dev checks , persistence等，记在心里。并非所有这些都会有用，但是能够访问一组可以轻松组合在一起工作的工具是很好的。

简单

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

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

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

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

另见 my answer on downsides of using Redux compared to Flux .