网站建设和连接器区公司名字,沈阳计算机培训短期速成班,户外广告公司,长兴住房和城乡建设局网站开始之前
Composition API 可以说是Vue3的最大特点#xff0c;那么为什么要推出Composition Api#xff0c;解决了什么问题#xff1f;
通常使用Vue2开发的项目#xff0c;普遍会存在以下问题#xff1a;
代码的可读性随着组件变大而变差每一种代码复用的方式#xff…
开始之前
Composition API 可以说是Vue3的最大特点那么为什么要推出Composition Api解决了什么问题
通常使用Vue2开发的项目普遍会存在以下问题
代码的可读性随着组件变大而变差每一种代码复用的方式都存在缺点TypeScript支持有限
以上通过使用Composition Api都能迎刃而解
正文
一、Options Api
Options API即大家常说的选项API即以vue为后缀的文件通过定义methodscomputedwatchdata等属性与方法共同处理页面逻辑
如下图 可以看到Options代码编写方式如果是组件状态则写在data属性上如果是方法则写在methods属性上…
用组件的选项 (data、computed、methods、watch) 组织逻辑在大多数情况下都有效
然而当组件变得复杂导致对应属性的列表也会增长这可能会导致组件难以阅读和理解
二、Composition Api
在 Vue3 Composition API 中组件根据逻辑功能来组织的一个功能所定义的所有 API 会放在一起更加的高内聚低耦合
即使项目很大功能很多我们都能快速的定位到这个功能所用到的所有 API 三、对比
下面对Composition Api 与Options Api进行两大方面的比较
逻辑组织逻辑复用
逻辑组织
Options API
假设一个组件是一个大型组件其内部有很多处理逻辑关注点对应下图不用颜色 可以看到这种碎片化使得理解和维护复杂组件变得困难
选项的分离掩盖了潜在的逻辑问题。此外在处理单个逻辑关注点时我们必须不断地“跳转”相关代码的选项块
Compostion API
而Compositon API正是解决上述问题将某个逻辑关注点相关的代码全都放在一个函数里这样当需要修改一个功能时就不再需要在文件中跳来跳去
下面举个简单例子将处理count属性相关的代码放在同一个函数了
function useCount() {let count ref(10);let double computed(() {return count.value * 2;});const handleConut () {count.value count.value * 2;};console.log(count);return {count,double,handleConut,};
}组件上中使用count
export default defineComponent({setup() {const { count, double, handleConut } useCount();return {count,double,handleConut}},
});再来一张图进行对比可以很直观地感受到 Composition API 在逻辑组织方面的优势以后修改一个属性功能的时候只需要跳到控制该属性的方法中即可 逻辑复用
在Vue2中我们是用过mixin去复用相同的逻辑
下面举个例子我们会另起一个mixin.js文件
export const MoveMixin {data() {return {x: 0,y: 0,};},methods: {handleKeyup(e) {console.log(e.code);// 上下左右 x yswitch (e.code) {case ArrowUp:this.y--;break;case ArrowDown:this.y;break;case ArrowLeft:this.x--;break;case ArrowRight:this.x;break;}},},mounted() {window.addEventListener(keyup, this.handleKeyup);},unmounted() {window.removeEventListener(keyup, this.handleKeyup);},
};然后在组件中使用
templatedivMouse position: x {{ x }} / y {{ y }}/div
/template
script
import mousePositionMixin from ./mouse
export default {mixins: [mousePositionMixin]
}
/script使用单个mixin似乎问题不大但是当我们一个组件混入大量不同的 mixins 的时候
mixins: [mousePositionMixin, fooMixin, barMixin, otherMixin]会存在两个非常明显的问题
命名冲突数据来源不清晰
现在通过Compositon API这种方式改写上面的代码
import { onMounted, onUnmounted, reactive } from vue;
export function useMove() {const position reactive({x: 0,y: 0,});const handleKeyup (e) {console.log(e.code);// 上下左右 x yswitch (e.code) {case ArrowUp:// y.value--;position.y--;break;case ArrowDown:// y.value;position.y;break;case ArrowLeft:// x.value--;position.x--;break;case ArrowRight:// x.value;position.x;break;}};onMounted(() {window.addEventListener(keyup, handleKeyup);});onUnmounted(() {window.removeEventListener(keyup, handleKeyup);});return { position };
}在组件中使用
templatedivMouse position: x {{ x }} / y {{ y }}/div
/templatescript
import { useMove } from ./useMove;
import { toRefs } from vue;
export default {setup() {const { position } useMove();const { x, y } toRefs(position);return {x,y,};},
};
/script可以看到整个数据来源清晰了即使去编写更多的 hook 函数也不会出现命名冲突的问题
小结
在逻辑组织和逻辑复用方面Composition API是优于Options API因为Composition API几乎是函数会有更好的类型推断。Composition API 对 tree-shaking 友好代码也更容易压缩Composition API中见不到this的使用减少了this指向不明的情况如果是小型组件可以继续使用Options API也是十分友好的
