龙空技术网

【译】Vue 何以对 React“降维打击”?

格子衬衫 6714

前言:

今天我们对“vue 走马灯”大体比较着重,大家都需要了解一些“vue 走马灯”的相关知识。那么小编也在网摘上收集了一些关于“vue 走马灯””的相关资讯,希望朋友们能喜欢,兄弟们一起来学习一下吧!

引言

JS(JavaScript)生态系统的现状可不是开玩笑的 —— 有一大坨东东:一龙一猪的库、框架以自己的方式实现一毛一样的东东。

我的个人心证是,这有好有坏 —— 存在一大坨选择,虽然但是,对于新手攻城狮而言,这可能导致“选择困难症晚期”,因为新手往往黑白不分。当然啦,人气即正义 —— 但祂们都人气爆棚。

私以为在这场“诸神之战”中,有两位高手独领风骚:React 和 Vue。一大坨道友在辩论其中之一是否更好,本文试图以我的知行合一为指导来揭晓此话题。

我的开端

我从 React 初出茅庐,当时知识有限,只完成了若干关于 HTML、CSS 和 JS 的必修课。由于 React 当时人气最高,私以为这是进军前端领域的必由之路。

我一头扎入才刚刚发布 app 路由器的 Next.js,开始啃文档并 DIY 我的“处女作”。那是一个致力于分享梦想的留言板 —— 如果您可以 get 到我的意思,我勉强算卡尔·荣格的粉丝。

完成该项目我感觉自己棒棒哒 —— 祂有授权、个人资料页面、表格和若干动画的优秀实践。如果您想查作业,这里是 任意门(现在有且仅有登陆和表格正常开工)。

虽然我已经用 React 达到预期目标,但我仍然在寻找更多的机会 —— 那就是我发现 Vue.js 的地方。祂已经处于成熟阶段,已经完成了向组合式 API 的过渡,看起来几乎和 React 一模一样。

起初,该文档吓尿我了,但多瞄了几眼后,我就坠入爱河无法自拔,现在我当然可以说祂是我最喜欢的现代 Web 框架(没有之一)。

学习曲线

那时,我还没有真正接触过 React 的文档,而 Vue 文档是我阅读由创建者自己编写、而不是某些内容制造商编写的任何类型教程的开端。

时至今日,如果您瞄一眼已经十分成熟的 React 文档升级版,私以为就学习而言 Vue 还是更加优秀。优点如下:

能解答一切的文档 —— React 的某些关键点和隐藏行为没有妥善归档,因为该文档有且仅有涵盖库的基本功能 —— 因此,每个 React 开发人员都必须知道与现代趋势同步的奇技淫巧。官方学习课程 —— Vueschool.io 和 Vuemastery.com 是学习 Vue 的美妙开局,而 React 有若干材料,其中大部分可能已经过时了。开发者友好的 API —— 于我而言,Vue 拥有更好且差异化的工具池,您可以用祂们开发 app。从第 1 页开始,祂们有很好的说明,并且比 React 更能为所欲为地控制您的 app。除此之外,文档中没有提到太多新手不友好的隐藏内容(渲染周期、useEffect)

当然啦,学习 React 对我后来学习 Vue 帮助很大 —— 在您打下坚实的基础并至少对一个框架有一定了解之后,您就能更快地驯服其他框架。

但即便如此,我还是会向每个新手推荐 Vue,因为就开发而言祂比 React 更宽容,而且很难搬起石头砸到自己的猫。

更好的装备

如上所述,Vue 固有的 API 比 React 更棒。此说法的几个关键点:

没有 useEffect

这意味着您不需要处理“弗兰肯斯坦(缝合怪)式”缺点,这些缺点是被那些无视 SOLID 的单一责任原则的人使用的。在 React 中,useEffect 是一把双刃剑 —— 组件生命周期的守护者和副作用的提供者。

这段代码的作用是什么?effect(作用)!

而这段代码?effect 返回?.....

返回数组?!

当您可以拥有一个具有无限用例的愚蠢抽象时,为什么要保留所有这些 onMounted / onUnmounted / onBeforeMount / onRouteChange / watch?只想在组件挂载时触发某些东东?提供一个空数组!为什么?因为抽象!

是的,大多数 React 爱好者可能都知道某些约定,但为什么不将祂们引入库本身并获得更好的体验呢?Hook yourself.

双向数据绑定

React 使用 Flux 架构,简而言之,这意味着数据能且仅能单向流动。这样做易于跟踪数据变化的地方,因为只有单一数据源。虽然 Vue 几乎相同 —— 但祂有祂的好处。

首先是输入绑定。使用 React,您需要编写如下内容来将输入值绑定到组件的状态:

这适用于每个输入组件。Vue 的等价功能是这样:

是的,您可以在 React 中编写一个自定义 hook 来处理所有同款功能,而不是在所有输入组件中重写它......但是何必呢?

其次是父子组件间的双向绑定,这意味着您可以通过 props 和父组件的数据通信,并通过 emits 从子组件回答父组件。在 React 中,为了处理子组件的某些数据,您可以这样写:

Vue 的等价功能类似:

哪种语法更好?假设我们 React 中有一个附带大约 20 个 props 的组件(这是一种极端情况,因为这是小概率事件,但不是不可能事件)。该组件的 props 接口类似于:

是的,您可以理解函数绑定从 on 开始,但为什么呢?没有传递给组件的函数是什么?祂会使您的 app 崩溃。在 Vue 中,这些东东会用 @ 符号来区分,并且其他每个开发者都会更好地理解到底发生了什么事。

编译器,而不是库

Vue 的另一个好处是祂为 .vue 文件提供了编译器,而不是使用纯粹的 JS 表达式。乍一听可能既变态又复杂 —— 但在您深入了解 React jsx 的变态和我下面将提到的其他事情之后,您就会明白我的观点了。

当 jsx 加入 React 时,有些人有点反感,某种程度上祂们是对的。经典的网页设计考虑了 3 个核心部分 —— HTML、CSS 和 JS。祂们旨在通过文件扩展名进行区分,并且关注点分离应该奏效。

虽然但是,现实世界中存在一大坨可复用逻辑,并且由于基于组件方法来创建界面的起源,私以为将祂们组合在一起是一个不错的决定,因为在三个文件之间切换(你好,Angular!)肯定不是一个好的体验。

但是 React 所做的 —— Vue 做得更好,原因如下:

不需要 CSS 文件 —— Vue 有一个 scoped 样式区块,您可以简单地设置所有样式。如果您不愿意,祂们不会在其他组件间共享。这样一来,React 的每个 CSS-in-JS 库就变得过时了,您不需要只为了能够编写十行代码,过度设计和创建一大坨 css modules。此外,如果您想避免使用 Tailwind,您不会被迫使用(˵ ͡° ͜ʖ ͡°˵)更好的约定 —— 没有 jsx,因此您不会迷路。想要让 html 标签触发某些事件(点击、选择.....)?只需添加 @ 并处理它:

想要设置 innerHtml?别担心,您不需要记住这一点:

只需要:

写太多也很危险,懂不?

需要一大坨 classNames 吗?连接字符串!

想要另辟蹊径?使用 库!(当然了,祂的大小低于 1 kb,但祂仍是一个外部依赖)

属性继承的处理要好得多。举个栗子,在 React 中,要将 className 传递给将来可能是动态的 UI 组件,您需要将其写在 props 中,然后将其传入组件的根 HTML 标签:

Vue 的等价功能就只需:

无需说明该组件需要占用祂。

是的,这褒贬不一,但如果您认为这是 React 更好的原因 —— 您似乎没有为每个组件编写 prop,这些组件会有一种极端情况,祂需要一个不应该成为其主题一部分的边界。

您也可以认为有时您不需要将属性直接传递给根标签 —— 而 Vue 为您提供了一个解决方案:

插槽更棒

要在 React 中将某些模板传递给子组件,您应该在组件的 props 中定义 children 属性,然后使用 jsx 大括号来渲染它:

而在 Vue 中,不仅更容易做到这一点,而且提供了更好的自由度来制作动态组件:

a. 您可以只留下 <slot/> 标签来处理 children 而不是 children:

b. 您可以有多个具名插槽:

c. 插槽可以会向父组件公开数据:

这对于孵化和其他组件梦幻联动的可复用组件非常有用(举个栗子,封装库的组件(走马灯等等......))

渲染由我

当 React 横空出世时,这是一个启示。在当时占主导地位的技术中,您必须自己编写所有重新渲染逻辑 —— 这就出现了一个可以刷掉其他所有内容的绝对解决方案, —— 只需重新渲染所有内容即可!

虽然祂解决了某些问题并使开发者的生活更轻松 —— 但它必有其缺陷。与其试图追赶重新渲染,不如确保您没有重新渲染。

memo 我的屁股!祂在过去效果很好,但我们,尤其是那些刚开始写代码的人,真的不需要步人后尘。

我并不是说您不应该掌握渲染周期并了解祂幕后的工作机制,但是当某些更新更好的技术能为您做到这点时,为什么每个人还需要亦步亦趋?

尽管 Vue 的渲染机制仍然依赖于类似 React 的虚拟 DOM(尤雨溪说将在 2024 年推出新的东东),但与炫酷的 Svelte 和 Solid 不同,祂仍然比 React 好得多,因为祂不是愚蠢地重新渲染所有内容,而是做了其他事情。

编译时,Vue 会跟踪每个需要更新的 DOM 节点,当其依赖发生变化时像外科手术一样精准更新祂。没有 useMemo / useCallback 以及过多响应性过时技术导致的性能瓶颈。

在 Vue 中,您宁愿找到一种方法来重新渲染你的组件,来规避此行为,私以为这比处理作者创建的某些不变的极端情况要好得多。

内置

至于某些非常适合包含在 UI 渲染解决方案中的工具,比如 React 和 Vue,Vue 也占了上风。当我想再次尝试 React 时,有时我邂逅了某个需求,需要使用 Vue 提供的开箱即用的 诸如 Transition 组件的东东。有了祂,您可以处理正在重新渲染的组件的动画。至于每个问题,React 确实为我的情况提供了一个 解决方案库。就这样,我感动得泪中带血,我开始泣不成声,我很抱歉,所以我只用纯粹的 css 处理动画。看啊:

您可能理解了祂的作用。

React 的等价功能是这样:

想要保持组件缓存,以便祂记住之前的数据并保持更好的性能?您得安装一个库!

而在 Vue 中:

React 想出了 Suspense —— 我很乐意!package.json 对于其中三者而言还不够大。

完结撒花

想到这篇文章,我得出了一个结论,私以为在这场框架之间的战争中最好的是 —— 您可以为所欲为,只是殊途同归。

如果您了解某件事的基础知识,您就会冷静看待您邂逅的每个库和框架。如果您只想盯着抽象层并比较祂们 —— 您必败无疑。

虽然但是,在选择要使用的工具时,我想在得出结论之前最好先尝试一下。

于我而言,React 感觉就像一个有技巧的老战士,但年龄越来越大,而某些新的年轻人身体状况良好,祂们没有被祂们的黑历史所束缚 —— 祂们正在另辟蹊径。

除此之外,这位老战士是由一个组织委托的,而年轻人是大家的英雄,祂们试图在阳光下赢得自己的位置,并将一大坨人民与祂们的战斗联系起来(我的意思是,Vue 是真正的开源,没有像 Meta 这样的东东背书)。

祂们每个人都屡战屡胜,老人拥有积年累月的庞大粉丝群,而 youngun 的粉丝则尖叫着永远支持祂。

如果没有 React,很可能就不会有这种 Vue,但如果没有 Vue 和其他框架,比如 Svelte 和 Solid,就会停滞不前。

作者:人猫神话

链接:

标签: #vue 走马灯