接下来我们就以前面创建的mini-vue3为基础来实现Vue3新增的API，首先要讲的就是Composition API。
什么是Compostion API呢？顾名思义，组合式API。相对而言我们在Vue2中使用的叫Options API，也即配置型API，我们的代码通过Vue给定的options，将代码写入到各个options中。比如mountd是虚拟dom装载完成之后的钩子，因此在SSR的服务端这个钩子不会执行。然后我们的data定义必须放到data中，计算属性则需要放在computed，以及methods等不同的options。
使用Option API的好处，我个人而言，觉得这个最大的好处就是降低了门槛，也就是说：因为你必须按照给定的option来组织你的代码，即使你的代码写的真的挺乱，但是因为有这个Options在，所以别人阅读你的代码还是有章可循的，知道从哪里开始，对应的方法应该去哪里找，也就是说提升了你的下限。既然提到了好处，自然要说下缺点。缺点就是因为功能点的分散。
比如我要想在created里面去拉取数据，然后进行渲染，我们可能得在method里定义两个方法，一个是拉取数据，一个是渲染数据。
然后我们要在created里面调用method里的方法A，在方法A里面我们去调用拉取数据的方法，然后再调用渲染数据的方法，因此会导致我们原本应该是写在一起的一个业务逻辑的代码要被分散到各处。当然这个主要是针对一些对性能或是代码架构有高要求的场景。一般的情况下确实并不需要这个。不过既然有场景，那也还是要能满足，因此Vue3推出了Composition API，通过setup方法来实现，我们可以看到官方文档对这个的定义：一组低侵入式的、函数式的 API，使得我们能够更灵活地「组合」组件的逻辑。而且这个对于Vue3来说是可选的，也就是说如果你不想用组合式API，那么你仍然可以继续使用Vue2的OptionAPI。
具体的相关API的文档可以参考Composition API
对于一些统一的这种业务逻辑代码，原来可能每个组件内都需要去写，而组件的重用并不是那么容易实现。不过通过组合式API，则可以将很多公共逻辑抽象为公共方法，然后就可以很好的复用了.
但是组合式API也有缺点，他的缺点就是因为太*了，所以对于水品没那么高的同学来说，很可能写的代码就能了一团乱麻，也就是所谓的面条代码。因此组合式API虽然可以提高上限，但是下限也低了。ok，说完了概念，就应该来具体实现了：