Vue3实践的一些问题清单

关于 vue3 的一些疑问点

1: 使用了 Vue3,是否都要遵循用 Composition API 的形式去写页面?

答案是否定的。需要注意一点:Vue3 并没有废弃 Options API,甚至还会全力支持兼容 Vue2 语法的工作。而 CompositionAPI 出现的背景主要是为了解决逻辑抽象和和复用的问题,但不意味着它成为了 Vue3 的标准。So,如何区分场景使用Options API or Composition API主要看业务逻辑的复杂程序,例如一些简单的 toast/button 等基础组件,用options API形式会更加清晰和简洁。而相对复杂的业务逻辑,可以用Composition API,可以把单独一块逻辑抽离到一个模块,通过 hook 函数的方式去解决。

2: Vue3 中混用 Options API 和 Composition API 会不会对性能产生影响?

不会。其实从问题 1 就可以明显地看出来并不会对性能产生任何影响。不应该被option api限制思维,而更多关注逻辑内聚问题

3: 关于 setup 中没有 this 的问题

官方文档是这么解释的:在 setup() 内部,this 不会是该活跃实例的引用,因为 setup() 是在解析其它组件选项之前被调用的,所以 setup() 内部的 this 的行为与其它选项中的 this 完全不同。这在和其它选项式 API 一起使用 setup() 时可能会导致混淆。这意味着,除了 props 之外,你将无法访问组件中声明的任何属性---本地状态,计算属性/方法。

但是从源码实现你会发现其实组件实例创建在前,函数之所以访问不到 this,是因为它在执行 setup 函数的时候,就没有把组件实例 instance 传给 setup。也没有把 this 指向实例 instance。So 执行顺序其实是:组件实例创建在 setup 函数执行之前,但是 setup 执行的时候,组件还没有 mounted,而晚于 beforeCreate 钩子,早于 create 钩子

4: reactive VS ref

刚开始看文档时,大家往往会去拿这两个去对比,总结一下:

reactive API: 可以把一个对象数据变成响应式(等同于 2.x 中的 Vue.observable())Composition API 更推荐用户主动定义响应式式数据,而非内部的黑盒处理

ref: 针对数组 or 对象本质就是reactive实现的,读取值时是ref.value

另外注意一下toRefs: 针对组合函数返回响应式对对象时使用 toRefs, 本质上是帮我们做了一层gettersetter处理,解构就可以得到响应式的数据,这也就降低了一些关于ref的心智负担

5: Vue3 响应式比 Vue2 的性能要好吗?

vue3 出来的时候,往往听到的一些答案都是说 Vue3 性能比 Vue2 性能好,但真的是吗?在 Vue3 发布那一段期间中(我也去薅羊毛薅到了 1 元的源码课解析中学习了一番:老黄 YYDS),甚至包括群里大家都在讨论这个问题。

首先从实现上来讲:我们都知道 vue2 中的响应式主要归功于Object.defineProperty, 它主要劫持对象的属性,所以它不能观测到对象属性的添加和删除,而在 vue 中,是用Proxy实现的,劫持的是整个对象,能规避掉 vue2 留下的问题,但也有明显的缺点就是兼容性不够强。但是对比 Vue2,你需要知道的是 vue3 性能上的优势主要还是体现在初始化阶段。因为 Vue2 中定位响应式对象时,会递归把子对象变成响应式。而 Vue3 其实是惰性执行:在对象属性被真正访问的时候才会递归执行子对象变成响应式。

6: Vue Composition API VS React Hooks

Vue3 的Composition APIReact Hooks的写法很像,大家都会忍不住拿他们去做个对比,关于这部分内容的 PK,我司的小伙伴已经给总结过了,还很全面,这个就不细说了

实践问题清单

除了一些常见的问题时,更重要的就是实践,对于新项目,可以直接使用 vue3 起步,但更多的对于已有的项目,在 vue2 升级到 vue3 实践时,肯定会踩不少坑,以下是关于在实践过程中可能会遇到的一些注意点&坑点

1. 报错以下警告:告知 script setup 当前仍然是个实验性的新特性,还没有作为正式特性发布,后面会不会有变化还不好说。

[@vue/compiler-sfc] 
                    
                    

你可能感兴趣的:(前端,vue.js,前端,javascript)