Vue3.0所采用的CompositionApi与Vue2.x使用的OptionsApi有什么不同

开始之前

Composition API 可以说是Vue3的最大特点&＃xff0c;那么为什么要推出Composition Api&＃xff0c;解决了什么问题&＃xff1f;

通常使用Vue2开发的项目&＃xff0c;普遍会存在以下问题&＃xff1a;

• 代码的可读性随着组件变大而变差
• 每一种代码复用的方式&＃xff0c;都存在缺点
• TypeScript支持有限

以上通过使用Composition Api都能迎刃而解

正文

一、Options Api

Options API&＃xff0c;即大家常说的选项API&＃xff0c;即以vue为后缀的文件&＃xff0c;通过定义methods&＃xff0c;computed&＃xff0c;watch&＃xff0c;data等属性与方法&＃xff0c;共同处理页面逻辑

如下图&＃xff1a;

可以看到Options代码编写方式&＃xff0c;如果是组件状态&＃xff0c;则写在data属性上&＃xff0c;如果是方法&＃xff0c;则写在methods属性上…

用组件的选项 (data、computed、methods、watch) 组织逻辑在大多数情况下都有效

然而&＃xff0c;当组件变得复杂&＃xff0c;导致对应属性的列表也会增长&＃xff0c;这可能会导致组件难以阅读和理解

二、Composition Api

在 Vue3 Composition API 中&＃xff0c;组件根据逻辑功能来组织的&＃xff0c;一个功能所定义的所有 API 会放在一起&＃xff08;更加的高内聚&＃xff0c;低耦合&＃xff09;

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

三、对比

下面对Composition Api与Options Api进行两大方面的比较

• 逻辑组织
• 逻辑复用

逻辑组织

Options API

假设一个组件是一个大型组件&＃xff0c;其内部有很多处理逻辑关注点&＃xff08;对应下图不用颜色&＃xff09;

可以看到&＃xff0c;这种碎片化使得理解和维护复杂组件变得困难

选项的分离掩盖了潜在的逻辑问题。此外&＃xff0c;在处理单个逻辑关注点时&＃xff0c;我们必须不断地“跳转”相关代码的选项块

Compostion API

而Compositon API正是解决上述问题&＃xff0c;将某个逻辑关注点相关的代码全都放在一个函数里&＃xff0c;这样当需要修改一个功能时&＃xff0c;就不再需要在文件中跳来跳去

下面举个简单例子&＃xff0c;将处理count属性相关的代码放在同一个函数了

function useCount() {let count &＃61; ref(10);let double &＃61; computed(() &＃61;> {return count.value * 2;});const handleConut &＃61; () &＃61;> {count.value &＃61; count.value * 2;};console.log(count);return {count,double,handleConut,};
}


组件上中使用count

export default defineComponent({setup() {const { count, double, handleConut } &＃61; useCount();return {count,double,handleConut}},
});


再来一张图进行对比&＃xff0c;可以很直观地感受到 Composition API在逻辑组织方面的优势&＃xff0c;以后修改一个属性功能的时候&＃xff0c;只需要跳到控制该属性的方法中即可

逻辑复用

在Vue2中&＃xff0c;我们是用过mixin去复用相同的逻辑

下面举个例子&＃xff0c;我们会另起一个mixin.js文件

export const MoveMixin &＃61; {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&＃43;&＃43;;break;case "ArrowLeft":this.x--;break;case "ArrowRight":this.x&＃43;&＃43;;break;}},},mounted() {window.addEventListener("keyup", this.handleKeyup);},unmounted() {window.removeEventListener("keyup", this.handleKeyup);},
};

然后在组件中使用

<template><div>Mouse position: x {{ x }} / y {{ y }}</div>
</template>
<script>
import mousePositionMixin from &＃39;./mouse&＃39;
export default {mixins: [mousePositionMixin]
}
</script>


使用单个mixin似乎问题不大&＃xff0c;但是当我们一个组件混入大量不同的 mixins 的时候

mixins: [mousePositionMixin, fooMixin, barMixin, otherMixin]


会存在两个非常明显的问题&＃xff1a;

• 命名冲突
• 数据来源不清晰

现在通过Compositon API这种方式改写上面的代码

import { onMounted, onUnmounted, reactive } from "vue";
export function useMove() {const position &＃61; reactive({x: 0,y: 0,});const handleKeyup &＃61; (e) &＃61;> {console.log(e.code);// 上下左右 x yswitch (e.code) {case "ArrowUp":// y.value--;position.y--;break;case "ArrowDown":// y.value&＃43;&＃43;;position.y&＃43;&＃43;;break;case "ArrowLeft":// x.value--;position.x--;break;case "ArrowRight":// x.value&＃43;&＃43;;position.x&＃43;&＃43;;break;}};onMounted(() &＃61;> {window.addEventListener("keyup", handleKeyup);});onUnmounted(() &＃61;> {window.removeEventListener("keyup", handleKeyup);});return { position };
}


在组件中使用

<template><div>Mouse position: x {{ x }} / y {{ y }}</div>
</template><script>
import { useMove } from "./useMove";
import { toRefs } from "vue";
export default {setup() {const { position } &＃61; useMove();const { x, y } &＃61; toRefs(position);return {x,y,};},
};
</script>


可以看到&＃xff0c;整个数据来源清晰了&＃xff0c;即使去编写更多的 hook 函数&＃xff0c;也不会出现命名冲突的问题

小结

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