为什么通过Facebook Flux使用Redux？

Question

我已经阅读了这个答案，减少了样板，看了几个GitHub示例，甚至尝试了一点redux（待办事项应用程序）。

据我了解，官方的redux doc动机与传统的MVC架构相比具有优势。但是它没有提供以下问题的答案：

为什么要通过Facebook Flux使用Redux？

这仅仅是编程风格的一个问题：功能性与非功能性？还是问题出在redux方法之后的abilities / dev-tools中？也许缩放？还是测试？

如果我说redux对于来自函数式语言的人来说是一种变化，那我是对的吗？

为了回答这个问题，您可以比较实现Redux在通量和Redux上的动机点的复杂性。

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

1. 处理乐观更新（据我所知，这几乎不依赖于第5点。很难在Facebook流量中实现它吗？）

2. 在服务器上渲染（facebook流量也可以做到这一点。与redux相比有什么好处吗？）

3. 在执行路线转换之前获取数据（为什么不能在facebook流量中实现它？有什么好处？）

4. 热重载（React Hot Reload可能实现。为什么需要redux？）

5. 撤消/重做功能

6. 还有其他要点吗？像坚持状态...

Answer 1

其次，您链接到的动机页面并没有真正讨论Redux的动机，而是讨论Flux（和React）背后的动机。尽管仍然没有解决与标准Flux架构在实现上的差异，但“ 三项原则”是Redux所特有的。基本上，Flux具有多个存储，这些存储可响应于与组件的UI / API交互来计算状态更改，并将这些更改作为组件可以订阅的事件进行广播。在Redux中，每个组件都只能订阅一个商店。IMO至少感觉到Redux通过统一（或减少，如Redux所说的）流回到组件的数据流来进一步简化和统一数据流-而Flux致力于统一数据流的另一面-模型。