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

2021-11-16 01:31:07 阅读：171 来源： 互联网

前言

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

选项式API的坏处

代码碎片化

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

先不说大组件的关注点会被拆分成怎么样，就单纯这一个很简单的演示就能够让各位同志体会到选项式 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。导致我点击了按钮之后页面未作出任何反应。

解决方法是，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' }
	}
}

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

不知道各位同志是否有感受到这种变化，笔者已经感受到组合式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 函数操作的已经是一个响应式数据了，所以，组件一旦用到了这个模块中的东西，它都会反映到页面中。

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

总结

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

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

标签：选项,Vue,浅谈,代码,value,API,calc,ref
来源： https://www.cnblogs.com/shiramashiro/p/15559307.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9