包阅导读总结
1. 组合式 API、Vue、代码规范、逻辑复用、最佳实践
2. 本文探讨了使用 Vue 组合式 API 中代码混乱的问题,总结了相关经验,提出最佳实践方案,包括规范书写顺序、抽取可复用逻辑为 hooks 文件或不可复用逻辑为 useXXX 函数,以实现代码易维护和清晰。
3.
– 组合式 API 特点与问题
– 特点:非常灵活
– 问题:因开发者差异和项目迭代导致代码混乱难以维护
– 选项式 API 优缺点
– 优点:代码书写位置固定,风格统一
– 缺点:组件逻辑复杂时不灵活,代码笨重
– 解决组合式 API 代码混乱的方案
– 有序书写:同一种 API 代码写在一处并按约定顺序
– 抽取 hooks:但非共享逻辑抽取为单个 hooks 文件不合适
– 最终方案:融合,抽取多个 useCount 函数在当前 vue 组件内
– 总结最佳实践
– 规范书写顺序和位置
– 按逻辑复用情况抽取
– 好处:便于逻辑复用和代码查看
思维导图:
文章地址:https://juejin.cn/post/7398046513811095592
文章来源:juejin.cn
作者:前端欧阳
发布时间:2024/8/1 23:30
语言:中文
总字数:2073字
预计阅读时间:9分钟
评分:82分
标签:Vue 3,组合式API,前端开发,代码规范,代码维护
以下为原文内容
本内容来源于用户推荐转载,旨在分享知识与观点,如有侵权请联系删除 联系邮箱 media@ilingban.com
前言
组合式 (Composition) API
的一大特点是“非常灵活”,但也因为非常灵活,每个开发都有自己的想法。加上项目的持续迭代导致我们的代码变得愈发混乱,最终到达无法维护的地步。本文是我这几年使用组合式API的一些经验总结,希望通过本文让你也能够写出易维护、优雅的组合式API
代码。
加入欧阳的高质量vue源码交流群、欧阳平时写文章参考的多本vue源码电子书
选项式API
vue2的选项式API因为每个选项都有固定的书写位置(比如数据就放在data
里面,方法就放在methods
里面),所以我们只需要将代码放到对应的选项中就行了。
优点是因为已经固定了每个代码的书写位置,所有人写出来的代码风格都差不多。
缺点是当单个组件的逻辑复杂到一定程度时,代码就会显得特别笨重,非常不灵活。
随意的写组合式API
vue3推出了组合式 (Composition) API
,他的主要特点就是非常灵活。解决了选项式API不够灵活的问题。但是灵活也是一把双刃剑,因为每个开发的编码水平不同。所以就出现了有的人使用组合式 (Composition) API写出来的代码非常漂亮和易维护,有的人写的代码确实很混乱和难易维护。
比如一个组件开始的时候还是规规矩矩的写,所有的ref
响应式变量放在一块,所有的方法放在一块,所有的computed
计算属性放在一块。
但是随着项目的不断迭代 ,或者干脆是换了一个人来维护。这时的代码可能就不是最开始那样清晰了,比如新加的代码不管是ref
、computed
还是方法都放到一起去了。如下图:
只有count1
和count2
时,代码看着还挺整齐的。但是随着count3
的代码加入后看着就比较凌乱了,后续如果再加count4
的代码就会更加乱了。
有序的写组合式API
为了解决上面的问题,所以我们约定了一个代码规范。同一种API的代码全部写在一个地方,比如所有的props
放在一块、所有的emits
放在一块、所有的computed
放在一块。并且这些模块的代码都按照约定的顺序去写,如下图:
随着vue组件的代码增加,上面的方案又有新的问题了。
还是前面的那个例子比如有5个count
的ref
变量,对应的computed
和methods
也有5个。此时我们的vue组件代码量就很多了,比如此时我想看看computed1
和increment1
的逻辑是怎么样的。
因为computed1
和increment1
函数分别在文件的computed
和methods
的代码块处,computed1
和increment1
之间隔了几十行代码,看完computed1
的代码再跳转去看increment1
的代码就很痛苦。如下图:
这时有小伙伴会说,抽成hooks
呗。这里有5个count
,那么就抽5个hooks
文件。像这样的代码。如下图:
一般来说抽取出来的hooks
都是用来多个组件进行逻辑共享,但是我们这里抽取出来的useCount
文件明显只有这个vue组件会用他。达不到逻辑共享的目的,所以单独将这些逻辑抽取成名为useCount
的hooks
文件又有点不合适。
最终解决方案
我们不如将前面的方案进行融合一下,抽取出多个useCount
函数放在当前vue组件内,而不是抽成单个hooks
文件。并且在多个useCount
函数中我们还是按照前面约定的规范,按照顺序去写ref
变量、computed
、函数的代码。
最终得出的最佳实践如下图:
上面这种写法有几个优势:
-
我们将每个
count
的逻辑都抽取成单独的useCount
函数,并且这些函数都在当前vue文件中,没有将其抽取成hooks
文件。如果哪天useCount1
中的逻辑需要给其他组件使用,我们只需要新建一个useCount
文件,然后直接将useCount1
函数的代码移到新建的文件中就可以了。 -
如果我们想查看
doubleCount1
和increment1
中的逻辑,只需要找到useCount1
函数,关于count1
相关的逻辑都在这个函数里面,无需像之前那样翻山越岭跨越几十行代码才能从doubleCount1
的代码跳转到increment1
的代码。
总结
本文介绍了使用Composition API
的最佳实践,规则如下:
-
首先约定了一个代码规范,
Composition API
按照约定的顺序进行书写(书写顺序可以按照公司代码规范适当调整)。并且同一种组合式API的代码全部写在一个地方,比如所有的props
放在一块、所有的emits
放在一块、所有的computed
放在一块。 -
如果逻辑能够多个组件复用就抽取成单独的
hooks
文件。 -
如果逻辑不能给多个组件复用,就将逻辑抽取成
useXXX
函数,将useXXX
函数的代码还是放到当前组件中。第一个好处是如果某天
useXXX
函数中的逻辑需要给其他组件复用,我们只需要将useXXX
函数的代码移到新建的hooks
文件中即可。第二个好处是我们想查看某个业务逻辑的代码,只需要在对应的
useXXX
函数中去找即可。无需在整个vue文件中翻山越岭从computed
模块的代码跳转到function
函数的代码。
最后推荐一下欧阳自己写的开源电子书vue3编译原理揭秘,这本书初中级前端能看懂。完全免费,只求一个star。