javascript – 为什么使用Redux而不是Facebook Flux？
作者：互联网
我已经阅读了this answer,reducing boilerplate,看了几个GitHub的例子,甚至尝试了redux(todo apps).
据我了解,official redux doc motivations提供了与传统MVC架构相比的优点.但它没有提供问题的答案：
为什么你应该使用Redux而不是Facebook Flux？
这只是编程风格的问题：功能与非功能？或者问题是在redux方法中遵循的能力/开发工具？也许缩放？还是测试？
如果我说redux对于来自函数式语言的人来说是一种变化,我是对的吗？
要回答这个问题,您可以比较实施redux在flux和redux上的动机点的复杂性.
以下是official redux doc motivations的动机要点：
>处理乐观更新(据我所知,它几乎不取决于第5点.难道在facebook flux中实现它吗？)
>在服务器上渲染(facebook flux也可以这样做.与redux相比有什么好处？)
>在执行路径转换之前获取数据(为什么在facebook中无法实现？有什么好处？)
>热重装(这可能是React Hot Reload.为什么我们需要redux？)
>撤消/重做功能
>还有其他一点吗？像坚持国家一样……
解决方法:
Redux的作者在这里！
Redux与Flux没有什么不同.总体而言,它具有相同的架构,但Redux能够通过使用Flux使用回调注册的功能组合来削减一些复杂角落.
Redux没有根本的区别,但我发现它使得某些抽象更容易,或者至少可以实现,这在Flux中很难或不可能实现.
减速剂成分
以分页为例.我的Flux + React Router example处理分页,但代码很糟糕.可怕的原因之一是Flux使得跨商店重用功能变得不自然.如果两个商店需要处理分页以响应不同的操作,它们或者需要从公共基本存储继承(糟糕！当您使用继承时将自己锁定到特定设计中),或者从内部调用外部定义的函数事件处理程序,需要以某种方式操作Flux存储的私有状态.整件事情很混乱(虽然绝对是可能的).
另一方面,由于减速器的成分,Redux的分页很自然.它一直是减速器,所以你可以写一个reducer factory that generates pagination reducers然后是use it in your reducer tree.关键是为什么它如此简单是因为在Flux中,商店是扁平的,但在Redux中,减速器可以通过功能组合嵌套,就像React组件一样嵌套.
这种模式还可以实现非用户代码undo/redo等精彩功能.您能想象将Undo / Redo插入到两行代码的Flux应用程序中吗？几乎不.使用Redux,再次归功于减速器组合模式.我需要强调的是,没有什么新鲜事 – 这是Elm Architecture中开创并详细描述的模式,它本身受到Flux的影响.
服务器渲染
人们使用Flux在服务器上渲染得很好,但是看到我们有20个Flux库,每个都试图让服务器呈现“更容易”,也许Flux在服务器上有一些粗糙的边缘.事实是Facebook没有做太多的服务器渲染,所以他们并没有非常关注它,并依靠生态系统来使它更容易.
在传统的Flux中,商店是单身人士.这意味着很难为服务器上的不同请求分离数据.不是不可能,但很难.这就是为什么大多数Flux库(以及新的Flux Utils)现在建议您使用类而不是单例,因此您可以按请求实例化存储.
您仍需要在Flux中解决以下问题(您自己或在您喜欢的Flux库(如Flummox或Alt)的帮助下)：
>如果商店是类,我如何根据请求使用调度程序创建和销毁它们？我什么时候注册商店？
>我如何保存商店中的数据,然后在客户端重新水化？我需要为此实现特殊方法吗？
不可否认,Flux框架(不是vanilla Flux)可以解决这些问题,但我发现它们过于复杂.例如,Flummox asks you to implement serialize() and deserialize() in your stores. Alt通过提供takeSnapshot()自动序列化JSON树中的状态来解决这个问题.
Redux更进一步：因为只有一个商店(由许多减速器管理),你不需要任何特殊的API来管理(重新)水合作用.您不需要“刷新”或“保湿”商店 – 只有一个商店,您可以读取其当前状态,或创建具有新状态的新商店.每个请求都有一个单独的商店实例. Read more about server rendering with Redux.
同样,这是Flux和Redux中可能存在的一种情况,但是Flux库通过引入大量API和约定来解决这个问题,而Redux甚至不必解决它,因为它没有解决这个问题.第一名归功于概念简洁.
开发经验
我实际上并不打算让Redux成为一个受欢迎的Flux库 – 我在ReactEurope talk on hot reloading with time travel上工作时写了它.我有一个主要目标：可以动态改变减速器代码甚至可以通过交叉“改变过去”退出行动,并看到重新计算的状态.
我还没有看到一个能够做到这一点的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的所有优点(记录和重放动作,单向数据流,依赖变异)并增加了新的好处(简单的撤销重做,热重新加载),而不引入Dispatcher和商店注册.
保持简单很重要,因为它可以在您实现更高级别的抽象时保持理智.
与大多数Flux库不同,Redux API表面很小.如果删除开发人员警告,注释和完整性检查,则为99 lines.没有棘手的异步代码可供调试.
您实际上可以阅读它并了解Redux的所有内容.
另见my answer on downsides of using Redux compared to Flux.
标签：reactjs-flux,javascript,reactjs,redux,flux 来源： https://codeday.me/bug/20190916/1807110.html