vue3.0记录-4(Composition-API对比Options API)

   Componsition API是vue3的一个很大的更新,也是很大的一个优点,为什么要更新呢?肯定是vue2的Options API有问题,本章就两者的区别做个介绍:

Options API

   又叫选项 API,以vue为后缀的文件，通过定义methods，computed，watch，data等属性与方法，共同处理页面逻辑,如下图:

优缺点

• 条例清晰,相同的放在相同的地方;但随着组件功能的增大,关联性会大大降低,组件的阅读和理解难度会增加;
• 调用使用this,但逻辑过多时this会出现问题,比如指向不明等;
• 其本身并不是有效的js代码 我们在使用options API 的时候,需要确切了解我们具体可以访问到哪些属性,以及我们访问到的当前属性的行为在后台,VUE需要将此属性转换为工作代码,因为 我们无法从自动建议和类型检查中受益,因此给我们在使用相关属性时,造成了一定弊端

Composition API

   又叫组合式API,组件根据逻辑功能来组织的，一个功能所定义的所有 API 会放在一起（更加的高内聚，低耦合）

   即使项目很大，功能很多，我们都能快速的定位到这个功能所用到的所有 API

优势 :

• 其代码更易读，更易理解和学习，没有任何幕后操作
• Composition API的好处不仅仅是以不同的方式进行编码，更重要的是对于代码的重用
• 不受模板和组件范围的限制，也可以准确的知道我们可以使用哪些属性
• 由于幕后没有什么操作，所以编辑器可以帮助我们进行类型检查和建议

对比

假设一个组件是一个大型组件，其内部有很多处理逻辑关注点（对应下图不用颜色）,在进行修改的时候,Composition API看起来更加的有条理,更加方便阅读

总结

• 在逻辑组织和逻辑复用方面，Composition API是优于Options API
• 因为Composition API几乎是函数，会有更好的类型推断。
• Composition API对 tree-shaking 友好，代码也更容易压缩
• Composition API中没有对this的使用，减少了this指向不明的情况
• 如果是小型组件，可以继续使用Options API，也是十分友好的

Composition API 是vue3.0一个核心的变更,书写格式被改变,
vue2.x中把数据放在data,把方法事件放在methods中,通过this进行调用;
在vue3.0中Composition API将同一个业务逻辑的代码(状态,也就是data,计算属性,方法等)都放在一起,有一些原生JavaScript的意思;
在Composition API中,没有了this,也不用担心指针的指向问题
生命周期也发生了改变,原来的created,beforeCreate被setup代替,原来的beforeDestroy,destroy改成了beforeUnmount,unmounted
还有很多,后面章节再讲~~