组合式 API FAQ - vue 进阶主题
组合式 API FAQ
什么是组合式 API?
组合式 API 是一系列 API 的集合,使我们可以使用函数而不是声明选项的方式书写 Vue 组件。它是一个概括性的术语,涵盖了以下方面的 API:
- 响应性 API:例如
ref()
和reactive()
,使我们可以直接创建响应式状态、计算属性和侦听器。 - 生命周期钩子:例如
onMounted()
和onUnmounted()
,使我们可以在组件各个生命周期阶段添加逻辑。 - 依赖注入:例如
provide()
和inject()
,使我们可以在使用响应性 API 时,利用 Vue 的依赖注入系统。
组合式 API 是 Vue 3 的内置功能,而要想在在 Vue 2 中使用,可以使用官方维护的插件 虽然这套 API 的风格是基于函数的组合,但组合式 API 并不是函数式编程。组合式 API 是以 Vue 中数据可变的、细粒度的响应性系统为基础的,而函数式编程更强调数据不可变。 如果你对如何通过组合式 API 使用 Vue 感兴趣,可以切换页面左侧边栏上方的 API 偏好到组合式 API,然后重新从头阅读指引。 组合式 API 最基本的优势是它使我们能够通过组合函数来实现更加简洁高效的逻辑复用。它解决了所有mixins的缺陷,那是选项式 API 中一种逻辑复用机制。 组合式 API 提供的更多逻辑复用可能性孵化了一些非常棒的社区项目,比如 VueUse,一个不断成长的工具型可组合函数集合。组合式 API 还为其他第三方状态管理库集成 Vue 的响应式系统提供了一套简洁清晰的机制,例如 RxJS。 许多用户都喜欢选项式 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 中享受到部分类型推导功能。 vue-class-component官方文档: vue-class-component是 vue 的官方库,作用是用类的方式编写组件。vue2.x 对 TS 的支持并不友好,所以 vue2.x 跟 TS 的整合,通常需要基于vue-class-component来用基于 class(类)的组件书写方式。然后现在 vue3.x 已出,对 TS 很友好的支持,所以使用 vue3.x ,不需要引用此 API。 搭配 对于有状态的逻辑来说,的确如此。当使用组合式 API 时,只需要用到一小部分选项: 如果你在代码中只使用了组合式 API(以及上述必需的选项),得益于编译时标记你可以减小生产包大概几 kb 左右的体积,因为丢掉了 Vue 之中关于选项式 API 的所有代码。注意这也会影响你依赖中的 Vue 组件。 可以。你可以在一个选项式 API 组件中使用 然而,我们只推荐你在就旧项目中这样使用。它们长期基于选项式 API 开发、又可能想要集成新的功能,或是想要集成基于组合式 API 的第三方库。 我们不再推荐在 Vue 3 中使用 Class API,因为组合式 API 提供了很好的TypeScript集成,并具有额外的逻辑重用和代码组织优势。 组合式 API 提供了和 React Hooks 相同级别的逻辑组织能力,但它们之间有着一些重要的区别。 React Hooks 在组件每次更新时都会重新调用。这就产生了一些即使是经验丰富的 React 开发人员也会感到困惑的问题。这也带来了一些性能问题,严重影响开发的体验。下面一些例子 相比起来,Vue 的组合式 API: 我们承认 React Hooks 的创造性,它是组合式 API 的一个主要灵感来源。然而,它的设计也确实存在上面提到的问题,而 Vue 的响应性模型恰好提供了绕过了它们。@vue/composition-api
。在 Vue 3 中,组合式 API 基本上都会配合 点击了:{{ count }} 次
为什么要有组合式 API?
更好的逻辑复用
更灵活的代码组织
更好的类型推导
https://class-component.vuejs.org
生产包体积更小
使用组合式 API 比等价情况下的选项式 API 更高效,对代码压缩也更友好。这是由于
;形式书写的组件模板被编译为了一个内连函数,和
中的代码位于同一作用域。不像选项式 API 需要依赖
this
上下文对象访问属性,被编译的模板可以直接访问中定义的变量,无需一个代码实例从中代理。这对代码压缩更友好,因为变量的名字可以变得更短,但对象的属性名则不能。
与选项式 API 的关系
组合式 API 是否覆盖了所有场景?
props
,emits
,name
和inheritAttrs
。如果使用,那么
inheritAttrs
应该是唯一一个需要用额外的块书写的选项了。
可以同时使用两种 API 吗?
setup()
选项。选项式 API 会被废弃吗?
不会,我们没有任何计划这样做。选项式 API 也是 Vue 不可分割的一部分,也有很多开发者喜欢它。我们也意识到组合式 API 主要适用于非常大型的项目,而对于中小型项目来说选项式 API 仍然是一个不错的选择。与 Class API 的关系
和 React Hooks 相比
useMemo
,这也需要传入正确的依赖数组。useCallback
作优化。这几乎是必需的,因此同样需要正确的依赖数组。忽视这一点会导致默认情况下对应用程序进行过度渲染,并可能在不知不觉中导致性能问题。setup()
或的代码一次。这使得代码能更好地与 JavaScript 的习惯性使用的直觉结合起来,因为不需要担心闭包变量的问题。组合式 API 也并不限制调用顺序,还可以有条件地进行调用。
鹏仔微信 15129739599 鹏仔QQ344225443 鹏仔前端 pjxi.com 共享博客 sharedbk.com
图片声明:本站部分配图来自网络。本站只作为美观性配图使用,无任何非法侵犯第三方意图,一切解释权归图片著作权方,本站不承担任何责任。如有恶意碰瓷者,必当奉陪到底严惩不贷!