[Vue]浅谈Vue3组合式API带来的好处以及选项API的坏处

  • A+
所属分类:Web前端
摘要

如果是经验不够多的同志在学习Vue的时候,在最开始会接触到Vue传统的方式(选项式API),后边会接触到Vue3的新方式 —— 组合式API。相信会有不少同志会陷入迷茫,因为我第一次听到新的名词时也陷入了困扰,所以,到底什么是组合式API呢?


前言

如果是经验不够多的同志在学习Vue的时候,在最开始会接触到Vue传统的方式(选项式API),后边会接触到Vue3的新方式 —— 组合式API。相信会有不少同志会陷入迷茫,因为我第一次听到新的名词时也陷入了困扰,所以,到底什么是组合式API呢?

选项式API的坏处

代码碎片化

通常在维护和开发一个组件时,分为 data、methods、computed、props 等。假如有一些业务在选项 API 的 data、methods、computed 中进行操作。把要关注的相同视角分别用不同颜色的框子框起来,发现我们的关注点被拆分成了这样:

[Vue]浅谈Vue3组合式API带来的好处以及选项API的坏处

先不说大组件的关注点会被拆分成怎么样,就单纯这一个很简单的演示就能够让各位同志体会到选项式 API 的坏处了。当我们的组件开始变得更大时,逻辑关注点的列表也会增长。如果你是一个军队的指挥官,你会选择把战线拉得很长吗?费时费力,后勤补给也跟不上。

这种碎片化使得理解和维护复杂组件变得困难,选项的分离掩盖了潜在的逻辑问题。此外,在处理单个逻辑关注点时,我们必须不断地“跳转”相关代码的选项块。

逻辑不复用

上一小节中说到选项式API使代码变得碎片化,曾经我想过把一段多次使用到的业务代码抽离到一个单独的 js 文件里。我也遇到过一些困扰的小问题,导致我不能完成理想。

首先,在 data 选项声明的变量才是响应式数据。其次,在 methods 选项声明的函数才可以操控组件里的响应式数据。这是下文分析选项式API逻辑不复用时的重要前提条件。

在 demo.js 文件里,我定义了一个 a 变量,calc 函数改变 a 的值:

export let a = 'foo' export function calc() { a = a + 'bar' } 

对于这样的抽离方式,在使用的时候,依旧是需要把变量导入到 data 选项,使其成为响应式数据;函数导入到 methods 选项。

import { a, calc } from './demo.js' export default {     data() { return { a } },     methods: { _calc() { calc() } } } 

由于 demo.js 文件里的函数操作的是 demo.js 文件里的变量 a ,而不是组件中响应式数据 a。导致我点击了按钮之后页面未作出任何反应。

[Vue]浅谈Vue3组合式API带来的好处以及选项API的坏处

解决方法是,calc 函数接受一个形参,然后再返回。当然可以!这只是一个简单的字符拼接而已。但是,这不是非常直接的办法,要经历一些曲折,同样会导致代码难读懂的问题。

官方提供的解决方案是混入,而混入还是在写选项API。不再选项API!不再选项API!不再选项API!,因为不符合期望。读到这里,想必知道了选项式API的坏处了。

一句话总结选项式API的坏处就是:代码碎片化、逻辑不复用

组合式API的好处

代码集中化

为什么组合式API就可以让代码不碎片化呢?因为组合式API的组合就在于它把变量、函数集中在一起,减少分离掩盖的潜在的逻辑问题,不在“跳转”相关代码的选项块。

所以,是如何集中化的呢?因为 Vue3 要实现代码集中化,所以,Vue3 的许多选项都抽离成为了一个个模块(这是我的猜想,因为每次用到什么必须从 vue 模块导入什么)。

组合式API就是一个 setup 函数,我们的所有代码全部都要写在这里面。

import { ref } from 'vue' export default { 	setup() {         let a = ref('foo')         function calcA() { a.value = a.value + 'bar' }         let b = ref('bar')         function calcB() { b.value = b.value + 'foo' }         let c = ref('hello')         function calcC() { c.value = c.value + 'world' }         let d = ref('world')        	function calcD() { d.value = d.value + 'hello' } 	} } 

现在,我们的关注点会被集中化,用图表示就是:

[Vue]浅谈Vue3组合式API带来的好处以及选项API的坏处

不知道各位同志是否有感受到这种变化,笔者已经感受到组合式API的强大了。

逻辑高复用

还记得第一章第二小节说到的问题吗?Vue3 的许多选项都抽离成为了一个个模块,所以我们可以在一个单独的 js 声明响应式数据了,就是利用ref函数来操作的。

我们新建一个 demo2.js 文件,首先引入 vue 模块中的 ref 函数,用于声明一个响应式数据:

import { ref } from 'vue' export let a = ref('foo') export function calc() { a.value = a.value + 'bar' } 

然后我们在其他组件中使用:

import { a, calc } from './demo2.js' export default {     setup() {         return { a, calc } // 这里需要导出a和calc     } } 

由于在 demo2.js 的 calc 函数操作的已经是一个响应式数据了,所以,组件一旦用到了这个模块中的东西,它都会反映到页面中。

[Vue]浅谈Vue3组合式API带来的好处以及选项API的坏处

大功告成,这得益于 Vue3 的一大进步啊!现在我们写代码可以写得非常舒服了。再加上 Vue3 是 TS 重构的,按道理来说是非常支持 TS 的写法的,前提是你的项目支持 TS。请问各位同志,Vue3 是不是可以适合开发大型应用了呢?

总结

将同一个逻辑关注点相关代码收集在一起,在处理单个逻辑关注点时,我们必须不断地“跳转”相关代码的选项块。使得开发人员更容易阅读和理解这些代码,这正是组合式 API 要解决的问题。

组合式 API 也导致以往的写法不相同,所以各位同志还是需要花时间去适应一段时间。