百科狗-知识改变命运!
--

vue和react(shouldComponentUpdate )性能异同

梵高1年前 (2023-12-15)阅读数 10#综合百科
文章标签组件子树

React 和 Vue 有许多相似之处,它们都有:

由于有着众多的相似处,我们会用更多的时间在这一块进行比较。这里我们不只保证技术内容的准确性,同时也兼顾了平衡的考量。我们需要承认 React 比 Vue 更好的地方,比如更丰富的生态系统。

React 和 Vue 都是非常快的,所以速度并不是在它们之中做选择的决定性因素。对于具体的数据表现,可以移步这个 第三方 benchmark ,它专注于渲染/更新非常简单的组件树的真实性能。

优化

在 React 应用中,当某个组件的状态发生变化时,它会以该组件为根,重新渲染整个组件子树。

如要避免不必要的子组件的重渲染,你需要在所有可能的地方使用 PureComponent ,或是手动实现 shouldComponentUpdate 方法。同时你可能会需要使用不可变的数据结构来使得你的组件更容易被优化。

然而,使用 PureComponent 和 shouldComponentUpdate 时,需要保证该组件的整个子树的渲染输出都是由该组件的 props 所决定的。如果不符合这个情况,那么此类优化就会导致难以察觉的渲染结果不一致。这使得 React 中的组件优化伴随着相当的心智负担。

在 Vue 应用中,组件的依赖是在渲染过程中自动追踪的,所以系统能精确知晓哪个组件确实需要被重渲染。你可以理解为每一个组件都已经自动获得了 shouldComponentUpdate ,并且没有上述的子树问题限制。

Vue 的这个特点使得开发者不再需要考虑此类优化,从而能够更好地专注于应用本身。

Vue和React的使用场景和深度有何不同

React和Vue已经是经常上PK台被惊醒比较的前端框架,我这边从以下几个方面对两者做一个比较,如果其中有理解不当的地方,请大家指正。

1、学习曲线

vue和react(shouldComponentUpdate )性能异同

React陡峭的学习曲线是一直被诟病的一点。Vue标榜的是一个渐进式的JavaScript框架,大部分开发者普遍会认为Vue的学习曲线低于React,并且相较于React有更丰富的中文支持(主要是Vue开发者是中国人,导致了很多我国的程序员都会关注此框架)。但是,随着学习内容的深入,当需要开发复杂的web应用程序时,花哨灵活的指令和逻辑反而会让人觉得Vue比React更难掌控。简单来说,React是一个陡坡比较难上手,Vue是一个缓坡很容易上手,但是最终的高度两者差不多。

2、技术社区

React是近十年的开源项目,因袭他拥有成熟的技术社区支持。Vue尽管这几年势头很猛,但是要想建立一套完善的生态系统还需要一些时间来打磨。

3、灵活性

这也是争议最大的地方。React 专注于 UI,所以在构建 UI 组件时可以从它那里获得很好的支持。Vue 作为一个渐进式框架,只允许使用最基本的功能来构建应用程序,但同时也提供了一些开箱即用的东西:如,用于状态管理的 Vuex、用于应用程序 URL 管理的 Vue Router、Vue 服务器端渲染。

Vue 剥离了许多元素,相比之下 React 更加全面。但如果您正在寻找一种精简、新颖、简单易学、样板代码少、高性能、灵活且完整的前端框架,Vue 更加适合;当然,如果您打算使用低版本 jQuery 代码,Vue 也同样支持。

React 的灵活性则更多依赖于其背后强大的技术社区,在 Facebook 的强力支撑下( Facebook 的 React 团队包括了 10 名专职开发人员),提供了更多工具、UI 库和教程。

综上所述,我个人觉得在没有实际应用场景的情况下,很难比较出孰优孰劣,没有最好的框架,只有最适合的框架。如果是短期小项目,建议使用 Vue 可以快速敏捷开发(上手快,控件占用小,性能较好)。如果是移动端跨平台的应用推荐 React( React Native 已经比较成熟而 Vue 的 Weex 仍在不断发展)。

首先,其实 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 不适合工程迭代,完全站不住脚。

鹏仔微信 15129739599 鹏仔QQ344225443 鹏仔前端 pjxi.com 共享博客 sharedbk.com

免责声明:我们致力于保护作者版权,注重分享,当前被刊用文章因无法核实真实出处,未能及时与作者取得联系,或有版权异议的,请联系管理员,我们会立即处理! 部分文章是来自自研大数据AI进行生成,内容摘自(百度百科,百度知道,头条百科,中国民法典,刑法,牛津词典,新华词典,汉语词典,国家院校,科普平台)等数据,内容仅供学习参考,不准确地方联系删除处理!邮箱:344225443@qq.com)

图片声明:本站部分配图来自网络。本站只作为美观性配图使用,无任何非法侵犯第三方意图,一切解释权归图片著作权方,本站不承担任何责任。如有恶意碰瓷者,必当奉陪到底严惩不贷!

内容声明:本文中引用的各种信息及资料(包括但不限于文字、数据、图表及超链接等)均来源于该信息及资料的相关主体(包括但不限于公司、媒体、协会等机构)的官方网站或公开发表的信息。部分内容参考包括:(百度百科,百度知道,头条百科,中国民法典,刑法,牛津词典,新华词典,汉语词典,国家院校,科普平台)等数据,内容仅供参考使用,不准确地方联系删除处理!本站为非盈利性质站点,本着为中国教育事业出一份力,发布内容不收取任何费用也不接任何广告!)