猿问
下载APP

请问该如何评价数据流管理架构 Redux?

如何评价数据流管理架构 Redux


慕瓜9086354
浏览 71回答 3
3回答

慕仰8121524

一套很优秀的框架。主要优点:1. 大幅降低了 Facebook 官方的 Flux 实现的冗余和不必要的复杂度,整体结构更为清晰和容易理解。2. 在 react-redux的配合下,完全分离了对数据的修改操作( Action / Reducer ) 和对数据的更新( Selector ),使得开发时可以在不考虑数据修改的情况下,优先完成整体视图逻辑,然后在添加对数据的修改操作等业务逻辑时几乎不用修改视图逻辑代码3. 单一数据源( Store )的模式使得数据管理、持久层方案选择和可调试性( Redux-Dev-Tools )都非常方便主要缺点:1. 对从 OOP 开发转过来的程序猿来说,函数式编程的概念接受起来需要一点门槛。2. JavaScript 对不变对象的支持并不是特别的友好,无论是引入 immutable.js 还是 ES6 的解构语法糖有时候都觉得 Reducer 里的代码读起来有些费力,特别是对刚接触 ES6的同学来说。3. 所有的 rackt · GitHub 旗下的框架,比如 rackt/react-router · GitHub 和 rackt/redux · GitHub ,以及 React 本身,都流露出一种 “ 老子就是要做最牛逼的东西,向下兼容这种事情根本就不是老子考虑的问题 ” 的态度。而且很多时候不是简单的不向下兼容,而是给人一种回炉重做的感觉。针对项目开发,一定要慎重选择版本。关于这一点 @杨森 可能会有话要说,他的博客里对 react-router 的教程已经更新了 N 版,仍然多次赶不上官方的 API 变化速度。综合结论:Redux 非常优秀,但是目前来看,比较适合喜欢折腾、自学能力强、熟练阅读 GitHub 上的官方英文文档并于官方在 issue 里谈笑风生的开发者去学习。当然,也许再过几个月,API 真的稳定了,然后诸位大神的中文文档也普及了,就能在国内有更大的发展了吧

喵喵时光机

React+Redux非常精炼,良好运用将发挥出极强劲的生产力。但最大的挑战来自于函数式编程(FP)范式。在工程化过程中,架构(顶层)设计将是一个巨大的挑战。要不然做出来的东西可能是一团乱麻。说到底,传统框架与react+redux就是OO与FP编程范式的对决。简单学习某项技术并不能让建立起一个全局理解,也很难工程化。所以,我们必须要看以下几方面:了解其独特的东西。如React中组件是pure render函数。置新技术于上下文中。将React放在flux、redux中。才能真正看到数据单向流动。对比看到优势。比其它的解决方案(vue, angluar,adobe flex),看其优势。挑战。软件领域里没有银弹,有好处一定有挑战。

隔江千里

首先,其实 Vue 也完全可以全量赋值的,唯一需要的小优化就是给 v-repeat 列表一个 track-by 属性,提示一下如何判断两个对象是否是同一份数据。如果是没有复杂交互的列表,可以直接 track-by="$index" 原地复用 DOM 元素。合理使用 track-by 的情况下,Vue 甚至可以比 React 更快(这里渲染的是 100 * 5 的数据表,每一帧都是全量新数据赋值):dbmon (Vue)dbmon (react)在超大量数据的首屏渲染速度上,React 有一定优势,因为 Vue 的渲染机制启动时候要做的工作比较多,而且 React 支持服务端渲染。需要指出的一点:React 的 Virtual DOM 也不是不需要优化的。复杂的应用里你有两个选择 1. 手动添加 shouldComponentUpdate 来避免不需要的 vdom re-render;2. Components 尽可能都用 pureRenderMixin,然后采用 Flux 结构 + Immutable.js。其实也不是那么简单的。相比之下,Vue 由于采用依赖追踪,默认就是优化状态:你动了多少数据,就触发多少更新,不多也不少。说起 Flux 架构,FB 提供的标准实现非常繁琐,所以社区的各种造轮子版本层出不穷,目前其实还没有找到一个公认的最佳实践,而且大部分新 Flux 实现都引入了很多函数式概念,你如果对函数式编程不熟悉,光搞清楚那些概念就得花很久。如果你真的理解了 Flux,你又会发现其实 Vue 也是可以应用 Flux 架构的。比如 optimizely/nuclear-js · GitHub 是一个 Flux 变种,他们就是同时把这个东西用在了 React 和 Vue 上面。再谈谈开发风格的偏好:React 推荐的做法是 JSX + inline style,也就是把 HTML 和 CSS 全都整进 JavaScript 了。Vue 的默认 API 是以简单易上手为目标,但是进阶之后推荐的是使用 webpack + vue-loader 的单文件组件格式:依然是熟悉的 HTML 和 CSS,但是可以放在一个文件里。而且你还可以使用你想要的预处理器,比如 LESS, Jade, Coffee, Babel,都可以。然后扯一扯模板 vs. JSX 的问题。JSX 在逻辑表达能力上虽然完爆模板,但是很容易写出凌乱的 render 函数,不如模板看起来一目了然。当然这里也有个人偏好的问题。React 的社区/组件生态比 Vue 大很多,这个是很显然的。不过说实话我很少见到现成的第三方组件完全符合我的要求。最后,使用场景上来说:React 配合严格的 Flux 架构,适合超大规模多人协作的复杂项目。理论上 Vue 配合类似架构也可以胜任这样的用例,但缺少类似 Flux 这样的官方架构。小快灵的项目上,Vue 和 React 的选择更多是开发风格的偏好。对于需要对 DOM 进行很多自定义操作的项目,Vue 的灵活性优于 React。---更新:楼下有些回答说 Vue 的核心是 MVVM 双向绑定,然后就直接跳跃到了『不适合持续工程迭代』的结论。且不说这样的跳跃太草率,这样的看法本身对于双向绑定的理解也是有偏差的。表单的双向绑定,说到底不过是 (value 的单向绑定 + onChange 事件侦听)的一个语法糖,你如果不想用 v-model,像 React 那样处理也是完全可以的。另一方面,组件间的数据传递,Vue 默认是单向的,和 React 一样。React 本身并不存在所谓的『单向数据流』,这完全是 Flux 引入的概念。其核心还是在于避免组件的 local state,强调把 state 抽取出来进行集中的管理。没有 Flux 的情况下 React 一样会有状态难以管理的问题,其根源在于在哪里存放和管理 state,和双向绑定没有本质联系。那难道 Vue 就不能这样管理状态吗?当然是可以的,Vue 现在可以通过 egoist/revue · GitHub 和 Redux 进行配合,也可以用 Vue 专属的状态管理架构 Vuex: vuejs/vuex · GitHub ,『单向数据流』并没有 React 吹的那么神,直接因为这一点就觉得 Vue 不适合工程迭代,完全站不住脚。
打开App,查看更多内容
随时随地看视频慕课网APP
我要回答