一、Vue2的常见缺陷

先看一看 Vue 2。从下图你能看到,Vue 2 是一个响应式驱动的、内置虚拟 DOM、组件化、用在浏览器开发,并且有一个运行时把这些模块很好地管理起来的框架。
在这里插入图片描述

1.首先从开发维护的角度来看

Vue2是使用Flow.js来做类型校验的,但是现在Flow.js已经停止维护了,整个社区都在全面使用TS来构建基础库,Vue团队也不例外

2.从社区的二次开发难度来说

Vue2内部运行时,是直接执行浏览器API的,但这样就会在Vue2的跨端方案中带来问题。要么直接进入Vue源码中与Vue一起维护,类似 Weex 文件夹中的代码,要么是直接复制一份全部的Vue代码,把浏览器API换成客户端或者小程序的。比如map Vue,但是Vue后续的更新就很难同步。

3.从我们普通开发者的角度来说

Vue2的响应式,并不是真正意义上的代理,而是基于Object.defineProperty()实现的,它只是对某个属性进行拦截,所以有很多缺陷,比如删除数据就无法舰艇,需要其他API辅助才可以,并且,Option API在组织代码较多的组件中使用不易维护,所有的methods、computed都在一个对象里配置,代码量多了之后就不易开发维护。

二、 Vue3的新特性

Vue3继承了Vue2的响应式、虚拟DOM、组件化等特点,并且全部重新设计,解决了历史问题,下面通过几个方面展开介绍Vue3。

1. RFC机制

这个特性和代码无关,RFC机制是Vue团队开发的工作方式。

这个改变让Vue社区更有活力,你可以在项目中看到每个需求从诞生到最终被Vue采纳的来龙去脉,这更好的帮助我们去了解Vue的发展。

RFC的引入,让Vue生态更加开放。

2. 响应式系统

Vue2 的响应式机制是基于Object.defineProperty()这个API实现的,此外,Vue还使用了Proxy,这两者看起来都像是对数据的读写进行拦截,但是Object.defineProperty() 是拦截对象中具体的某个属性,而Proxy才是真正的代理,它可以拦截/监控所有的属性。

Object.defineProperty(obj, 'title', {
  get() {},
  set() {},
})

当获取属性中的值Obj.title 或者修改Obj.title时,会被defineProperty拦截,但是它无法对不存在的属性拦截,所以在Vue2中,所有数据必须事先在data中声明。

使用真正的代理Proxy

Object.Proxy(obj, {
  get() {},
  set() {},
})

Proxy可以拦截obj这个数据,但是具体是哪个属性值,Proxy并不关心,而且Proxy可以监听更多的数据格式,比如Set、Map,这是Vue2做不到的。

Proxy存在兼容问题,在低版本浏览器中(比如IE11以下)Vue3无法使用。

3. 自定义渲染器

通过上面的图可以知道,Vue2所有的模块都是杂糅在一起的,这样做会导致不好拓展的问题,Vue3是怎么解决的呢?重构-拆包,使用monoerpo管理方式,响应式、编译和运行就全部独立了
在这里插入图片描述
Vue3中,响应式独立了出来,而Vue2中的响应式只服务于Vue,Vue3中响应式与Vue解耦,你甚至可以在NodeJ S和React中使用响应式。
在这里插入图片描述

渲染逻辑也被拆分为 平台无关渲染逻辑 和 浏览器渲染API 两部分。

可以发现在这个架构下,使用Vue3开发小程序、开发canvans小游戏以及开发客户端的时候,就不用使用全部Vue代码,只需要事先平台的渲染逻辑就可以。

3.全部模块使用TS重构

TS强类型系统带来了更方便的提示,让代码更加优雅稳重。

具体可以自行了解TS的特性。

4. Composition API

组合式API(Composition API) 是一系列 API 的集合,使我们可以使用函数而不是声明选项的方式书写 Vue 组件。

Options API 的几个很严重的问题:

  1. 所有数据都挂载在 this 之上,Option API对TS的类型推导很不友好,并且不利于Tree-shaking清理代码
  2. 新增功能大部分都需要修改data、method等配置,并且在代码量大时,经常需要上下横跳
  3. 代码不好复用,逻辑不好抽离,并且有命名冲突的问题

Composition API 对我们开发 Vue 项目起到了巨大的帮助。

Composition API可以让我们通过组合函数来实现更加简洁高效的逻辑复用,并且它拥有更灵活的代码组织
在这里插入图片描述

5. Vite

新一代工程化工具 Vite是独立的打包工具,并不在Vue3的代码包内。

先说一下Webpack的原理,它根据你的import依赖逻辑,形成一个依赖图,然后调试对应的处理工具,把整个项目打包之后,放在内存里再启动调试。由于预打包,所以复杂项目的开发,启动调试环境都需要很久,Vite就是为了解决这个时间资源的消耗而出现。

在调试环境下,我们不需要全部预打包,只需把首页依赖的文件,依次通过网络请求去获取,这样就提升了整个开发的体验,做到了复杂项目的秒级调试和热更新。

Webpack原理,Webpack 要把所有路由的依赖打包后,才能开始调试。
在这里插入图片描述

Vite原理,一开始就可以准备联调,然后根据首页的依赖模块,再去按需加载,这样启动调试所需要的资源会大大减少。
在这里插入图片描述

Logo

前往低代码交流专区

更多推荐