Vue2.x 开发的项目,普遍存在以下问题:
- 代码可读性随组件变大而变差。
- 每一种代码复用的方式,都存在缺点。
- TypeScript 支持有限。
Vue3 的 Composition API 都可以迎刃而解。
Options API
是大家说的选项式 API,即以 vue 为后缀的文件,通过定义 data、methods、computed、watch 等属性和方法,共同处理页面逻辑。
当组件变的复杂,导致对应属性的列表也会增加,这可能导致组件难以阅读和理解。
Composition API
Composition API 的组件是根据逻辑功能来组织的,一个功能所定义的所有 API 会放在一起(更加高内聚、低耦合)。
即使项目很大,功能很多,我们都能快速的定位到这个功能用到的所有 API。
从逻辑组织和逻辑复用两方面对比:
-
逻辑组织
Options 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,
};
}
在组件中使用:
export default defineComponent({
setup() {
const { count, double, handleConut } = useCount();
return {
count,
double,
handleConut
}
},
});
-
逻辑复用
在
Vue2中,我们是用过mixin去复用相同的逻辑,会存在两个非常明显的问题:- 命名冲突
- 数据来源不清晰
通过 Composition 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 y
switch (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 };
}
在组件中使用
<template>
<div>
Mouse position: x {{ x }} / y {{ y }}
</div>
</template>
<script>
import { useMove } from "./useMove";
import { toRefs } from "vue";
export default {
setup() {
const { position } = useMove();
const { x, y } = toRefs(position);
return {
x,
y,
};
},
};
</script>
总结
-
在逻辑组织和逻辑复用方面,Compoition API 是优于 Options API。
-
因为 Composition API 几乎是函数,会有更好的类型判断。
-
Composition API 对 tree-shaking 友好,代码也更容易压缩。
-
Composition API 中见不到 this 的使用,减少了 this 指向不明的情况。
-
如果是小型组件,可以继续使用 Options API,也是十分友好的。