Vue3中的组合式 API示例详解

目录

• 为什么要有组合式 API？
• 更好的逻辑复用
• 更灵活的代码组织
• 更好的类型推导
• 生产包体积更小
• 与选项式 API 的关系
• 组合式 API 是否覆盖了所有场景？
• 可以同时使用两种 API 吗？
• 选项式 API 会被废弃吗？

组合式 API 是一系列 API 的集合，使我们可以使用函数而不是声明选项的方式书写 Vue 组件。它是一个概括性的术语，涵盖了以下方面的 API：

• 响应性 API：例如ref()和reactive()，使我们可以直接创建响应式状态、计算属性和侦听器。
• 生命周期钩子：例如onMounted()和onUnmounted()，使我们可以在组件各个生命周期阶段添加逻辑。
• 依赖注入：例如provide()和inject()，使我们可以在使用响应性 API 时，利用 Vue 的依赖注入系统。

在 Vue 3 中，组合式 API 基本上都会配合

虽然这套 API 的风格是基于函数的组合，但组合式 API 并不是函数式编程。组合式 API 是以 Vue 中数据可变的、细粒度的响应性系统为基础的，而函数式编程更强调数据不可变。

为什么要有组合式 API？

更好的逻辑复用

组合式 API 最基本的优势是它使我们能够通过组合函数来实现更加简洁高效的逻辑复用。它解决了所有mixins的缺陷，那是选项式 API 中一种逻辑复用机制。

更灵活的代码组织

许多用户都喜欢选项式 API，因为在默认情况下就能够写出有组织的代码：任何东西都有其对应的选项来管理。然而，选项式 API 在单个组件的逻辑复杂到一定程度时，也面临了一些无法忽视的限制。这些限制主要体现在需要处理多个逻辑关注点的组件中，在许多 Vue 2 已经上线的生产应用中可以看到这一点。

我们以 Vue CLI GUI 中的文件浏览器组件为例：这个组件承担了以下几个逻辑关注点：

• 追踪当前文件夹的状态，展示其内容
• 处理文件夹的相关操作(打开、关闭和刷新)
• 支持创建新文件夹
• 可以切换到只展示收藏的文件夹
• 可以开启对隐藏文件夹的展示
• 处理当前工作目录中的变更

这个组件最原始的版本是由选项式 API 写成的。而如果用组合式 API 重构这个组件，将会变成：

现在与同一个逻辑关注点相关的代码被归为了一组：我们无需再为了一个逻辑关注点在不同的选项块间来回滚动切换。此外，我们现在可以不费吹灰之力地将这一组代码移动到一个外部文件中，不再需要为了抽象而重新组织代码，大大降低了重构成本，这在长期维护的大型项目中非常关键。

更好的类型推导

近几年来，越来越多的开发者开始使用TypeScript书写更健壮可靠的代码，TypeScript还提供了非常好的IDE 开发支持。然而选项式 API 是在 2013

年创建的，那时并没有想到需要进行类型推导。因此我们做了一些荒谬复杂的类型体操来实现对选项式 API 的类型推导。但尽管做了这么多的努力，选项式 API 的类型推导仍然无法适配混入和依赖注入。

因此，很多想要搭配 TS 使用 Vue 的开发者采用了由vue-class-component提供的Class API。然而，基于 Class 的 API 非常依赖 ES 装饰器，在 Vue 2019 年开发完成后，它仍是一个仅处于 vue 2的语言功能。我们认为将这样一种不稳定的方案作为官方 API 的一种实现形式风险过高，在那之后装饰器提案还进行了一些较大的变动，在书写这篇文档时仍未到达 vue 3。另外，基于 Class 的 API 和选项式 API 在逻辑复用和代码组织方面有相同的限制。

相比之下，组合式 API 主要利用基本的变量和函数，它们本身就是类型友好的。用组合式 API 重写的代码可以享受到完整的类型推导，不需要书写太多类型标注。大多数时候，用 TypeScript 书写的组合式 API 代码和用 JavaScript 写都差不太多！这也同样让许多纯 JavaScript 用户能从IDE 中享受到部分类型推导功能。

生产包体积更小

搭配