第一次试用vue3的组合式API，十分不适应。于是想知道组合式API的优点是什么，为什么vue3中要单独拎出来重点说明。下面就来探讨一下。

代码的组织

不管是选项式API还是组合式API，他们都是一种代码组织方式。那么这两种组织方式孰优孰劣呢？

官网的说法是：把在vue2中分散在各选项中的数据上相关的资源（下称data、computed、watch、methods等称为资源）集中在一起，这对于代码量多的vue文件很有帮助，因为减少了来回上下找代码的问题。通常用下图表示：

但我并不十分赞同这种说法。一是代码量大了，使用组合式API组织的代码也要面临上下翻找的问题；二是上图所表达的观点是从资源功能的角度来看待，但是如果从资源类型的角度来看待，则选项式API紧凑，而组合式API分散。

更优的代码复用方式

在vue2中，代码的复用是通过mixin来实现的。而mixin的缺点非常明显，包括：

1. 数据来源不清晰：当使用多个mixin时，实例上的数据属性来自哪个mixin变得不清晰，这使得追溯和理解组件行为变得困难。
2. 命名空间冲突：当使用多个mixin时，这些mixin之间可能会注册相同的属性名和方法名，造成命名冲突。
3. mixin之间的合作关系不清晰：当使用多个mixin时，有些mixin之间具有合作关系，而我们无法从代码中直观地看出这些mixin之间有什么样的合作关系。

而组合式API就解决了如上的问题：

1. 我们显式地结构响应式函数的返回值来获取数据，能明确地看到数据来源。
2. 若多个响应式函数的返回值中有同名函数，则编译器会报错，从而避免了同名属性覆盖的问题。
3. 一个响应式函数的返回值可以作为另一个响应式函数的参数传入，从代码中可以看出这些响应式函数的合作关系。

对TS的支持

vue2对ts的支持是非常不友好的，不仅需要有繁杂的配置，还不能支持使用this访问实例资源。见以下例子：

<script lang="ts">
export default {
	data() {
		count: 0
	},
  computed: {
    navigateCount() {
      return this.count // ts报错，因为这里的this指向的是computed对象而不是data对象
    }
  },
  methods: {
    increaseCount() {
      this.count++ // ts报错，因为这里的this指向的是methods对象而不是data对象
    }
  },
  mounted() {
    console.log(this.count) // ts报错，因为这里的this指向的是vue实例而不是data对象
    console.log(this.$data.count) // ts通过，因为this.$data指向的是data对象
  }
}
</script>

这个问题在组合式API中是不存在的，因为组合式API中不需要使用this。