前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >用了组合式 (Composition) API 后代码变得更乱了,怎么办?

用了组合式 (Composition) API 后代码变得更乱了,怎么办?

作者头像
前端欧阳
发布2024-08-02 13:43:26
1340
发布2024-08-02 13:43:26
举报
文章被收录于专栏:vue3编译原理揭秘

大家好,我是欧阳,又跟大家见面啦! 欧阳写了一本vue3编译原理揭秘开源电子书,这本书初中级前端都能看懂。完全免费,只求一个star,点击文末的阅读原文跳转到电子书。

前言

组合式 (Composition) API 的一大特点是“非常灵活”,但也因为非常灵活,每个开发都有自己的想法。加上项目的持续迭代导致我们的代码变得愈发混乱,最终到达无法维护的地步。本文是我这几年使用组合式API的一些经验总结,希望通过本文让你也能够写出易维护优雅组合式API代码。

选项式API

vue2的选项式API因为每个选项都有固定的书写位置(比如数据就放在data里面,方法就放在methods里面),所以我们只需要将代码放到对应的选项中就行了。

优点是因为已经固定了每个代码的书写位置,所有人写出来的代码风格都差不多。

缺点是当单个组件的逻辑复杂到一定程度时,代码就会显得特别笨重,非常不灵活。

随意的写组合式API

vue3推出了组合式 (Composition) API,他的主要特点就是非常灵活。解决了选项式API不够灵活的问题。但是灵活也是一把双刃剑,因为每个开发的编码水平不同。所以就出现了有的人使用组合式 (Composition) API写出来的代码非常漂亮和易维护,有的人写的代码确实很混乱和难易维护。

比如一个组件开始的时候还是规规矩矩的写,所有的ref响应式变量放在一块,所有的方法放在一块,所有的computed计算属性放在一块。

但是随着项目的不断迭代 ,或者干脆是换了一个人来维护。这时的代码可能就不是最开始那样清晰了,比如新加的代码不管是refcomputed还是方法都放到一起去了。如下图:

只有count1count2时,代码看着还挺整齐的。但是随着count3的代码加入后看着就比较凌乱了,后续如果再加count4的代码就会更加乱了。

有序的写组合式API

为了解决上面的问题,所以我们约定了一个代码规范。同一种API的代码全部写在一个地方,比如所有的props放在一块、所有的emits放在一块、所有的computed放在一块。并且这些模块的代码都按照约定的顺序去写,如下图:

随着vue组件的代码增加,上面的方案又有新的问题了。

还是前面的那个例子比如有5个countref变量,对应的computedmethods也有5个。此时我们的vue组件代码量就很多了,比如此时我想看看computed1increment1的逻辑是怎么样的。

因为computed1increment1函数分别在文件的computedmethods的代码块处,computed1increment1之间隔了几十行代码,看完computed1的代码再跳转去看increment1的代码就很痛苦。如下图:

这时有小伙伴会说,抽成hooks呗。这里有5个count,那么就抽5个hooks文件。像这样的代码。如下图:

一般来说抽取出来的hooks都是用来多个组件进行逻辑共享,但是我们这里抽取出来的useCount文件明显只有这个vue组件会用他。达不到逻辑共享的目的,所以单独将这些逻辑抽取成名为useCounthooks文件又有点不合适。

最终解决方案

我们不如将前面的方案进行融合一下,抽取出多个useCount函数放在当前vue组件内,而不是抽成单个hooks文件。并且在多个useCount函数中我们还是按照前面约定的规范,按照顺序去写ref变量、computed、函数的代码。

最终得出的最佳实践如下图:

上面这种写法有几个优势:

  • 我们将每个count的逻辑都抽取成单独的useCount函数,并且这些函数都在当前vue文件中,没有将其抽取成hooks文件。如果哪天useCount1中的逻辑需要给其他组件使用,我们只需要新建一个useCount文件,然后直接将useCount1函数的代码移到新建的文件中就可以了。
  • 如果我们想查看doubleCount1increment1中的逻辑,只需要找到useCount1函数,关于count1相关的逻辑都在这个函数里面,无需像之前那样翻山越岭跨越几十行代码才能从doubleCount1的代码跳转到increment1的代码。

总结

本文介绍了使用Composition API的最佳实践,规则如下:

  • 首先约定了一个代码规范,Composition API按照约定的顺序进行书写(书写顺序可以按照公司代码规范适当调整)。并且同一种组合式API的代码全部写在一个地方,比如所有的props放在一块、所有的emits放在一块、所有的computed放在一块。
  • 如果逻辑能够多个组件复用就抽取成单独的hooks文件。
  • 如果逻辑不能给多个组件复用,就将逻辑抽取成useXXX函数,将useXXX函数的代码还是放到当前组件中。 第一个好处是如果某天useXXX函数中的逻辑需要给其他组件复用,我们只需要将useXXX函数的代码移到新建的hooks文件中即可。 第二个好处是我们想查看某个业务逻辑的代码,只需要在对应的useXXX函数中去找即可。无需在整个vue文件中翻山越岭从computed模块的代码跳转到function函数的代码。
本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2024-08-01,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 前端欧阳 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 前言
  • 选项式API
  • 随意的写组合式API
  • 有序的写组合式API
  • 最终解决方案
  • 总结
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档