組合式 (Composition) API 的一大特點是“非常靈活”，但也因為非常靈活，每個開發(fā)都有自己的想法。加上項目的持續(xù)迭代導(dǎo)致我們的代碼變得愈發(fā)混亂，最終到達(dá)無法維護(hù)的地步。本文是我這幾年使用組合式API的一些經(jīng)驗總結(jié)，希望通過本文讓你也能夠?qū)懗?strong style="color: rgb(53, 179, 120);background-attachment: scroll;background-clip: border-box;background-image: none;background-origin: padding-box;background-position: 0% 0%;background-repeat: no-repeat;background-size: auto;width: auto;height: auto;border-style: none;border-width: 3px;border-color: rgba(0, 0, 0, 0.4);border-radius: 0px;">易維護(hù)、優(yōu)雅的組合式API代碼。

選項式API

vue2的選項式API因為每個選項都有固定的書寫位置（比如數(shù)據(jù)就放在data里面，方法就放在methods里面），所以我們只需要將代碼放到對應(yīng)的選項中就行了。

優(yōu)點是因為已經(jīng)固定了每個代碼的書寫位置，所有人寫出來的代碼風(fēng)格都差不多。

缺點是當(dāng)單個組件的邏輯復(fù)雜到一定程度時，代碼就會顯得特別笨重，非常不靈活。

隨意的寫組合式API

vue3推出了組合式 (Composition) API，他的主要特點就是非常靈活。解決了選項式API不夠靈活的問題。但是靈活也是一把雙刃劍，因為每個開發(fā)的編碼水平不同。所以就出現(xiàn)了有的人使用組合式 (Composition) API寫出來的代碼非常漂亮和易維護(hù)，有的人寫的代碼確實很混亂和難易維護(hù)。

比如一個組件開始的時候還是規(guī)規(guī)矩矩的寫，所有的ref響應(yīng)式變量放在一塊，所有的方法放在一塊，所有的computed計算屬性放在一塊。

但是隨著項目的不斷迭代 ，或者干脆是換了一個人來維護(hù)。這時的代碼可能就不是最開始那樣清晰了，比如新加的代碼不管是ref、computed還是方法都放到一起去了。如下圖：

只有count1和count2時，代碼看著還挺整齊的。但是隨著count3的代碼加入后看著就比較凌亂了，后續(xù)如果再加count4的代碼就會更加亂了。

有序的寫組合式API

為了解決上面的問題，所以我們約定了一個代碼規(guī)范。同一種API的代碼全部寫在一個地方，比如所有的props放在一塊、所有的emits放在一塊、所有的computed放在一塊。并且這些模塊的代碼都按照約定的順序去寫，如下圖：

隨著vue組件的代碼增加，上面的方案又有新的問題了。

還是前面的那個例子比如有5個count的ref變量，對應(yīng)的computed和methods也有5個。此時我們的vue組件代碼量就很多了，比如此時我想看看computed1和increment1的邏輯是怎么樣的。

因為computed1和increment1函數(shù)分別在文件的computed和methods的代碼塊處，computed1和increment1之間隔了幾十行代碼，看完computed1的代碼再跳轉(zhuǎn)去看increment1的代碼就很痛苦。如下圖：

這時有小伙伴會說，抽成hooks唄。這里有5個count，那么就抽5個hooks文件。像這樣的代碼。如下圖：

一般來說抽取出來的hooks都是用來多個組件進(jìn)行邏輯共享，但是我們這里抽取出來的useCount文件明顯只有這個vue組件會用他。達(dá)不到邏輯共享的目的，所以單獨將這些邏輯抽取成名為useCount的hooks文件又有點不合適。

最終解決方案

我們不如將前面的方案進(jìn)行融合一下，抽取出多個useCount函數(shù)放在當(dāng)前vue組件內(nèi)，而不是抽成單個hooks文件。并且在多個useCount函數(shù)中我們還是按照前面約定的規(guī)范，按照順序去寫ref變量、computed、函數(shù)的代碼。

最終得出的最佳實踐如下圖：

上面這種寫法有幾個優(yōu)勢：

• 我們將每個count的邏輯都抽取成單獨的useCount函數(shù)，并且這些函數(shù)都在當(dāng)前vue文件中，沒有將其抽取成hooks文件。如果哪天useCount1中的邏輯需要給其他組件使用，我們只需要新建一個useCount文件，然后直接將useCount1函數(shù)的代碼移到新建的文件中就可以了。

• 如果我們想查看doubleCount1和increment1中的邏輯，只需要找到useCount1函數(shù)，關(guān)于count1相關(guān)的邏輯都在這個函數(shù)里面，無需像之前那樣翻山越嶺跨越幾十行代碼才能從doubleCount1的代碼跳轉(zhuǎn)到increment1的代碼。

總結(jié)

本文介紹了使用Composition API的最佳實踐，規(guī)則如下：

• 首先約定了一個代碼規(guī)范，Composition API按照約定的順序進(jìn)行書寫（書寫順序可以按照公司代碼規(guī)范適當(dāng)調(diào)整）。并且同一種組合式API的代碼全部寫在一個地方，比如所有的props放在一塊、所有的emits放在一塊、所有的computed放在一塊。

• 如果邏輯能夠多個組件復(fù)用就抽取成單獨的hooks文件。

• 如果邏輯不能給多個組件復(fù)用，就將邏輯抽取成useXXX函數(shù)，將useXXX函數(shù)的代碼還是放到當(dāng)前組件中。

  第一個好處是如果某天useXXX函數(shù)中的邏輯需要給其他組件復(fù)用，我們只需要將useXXX函數(shù)的代碼移到新建的hooks文件中即可。

  第二個好處是我們想查看某個業(yè)務(wù)邏輯的代碼，只需要在對應(yīng)的useXXX函數(shù)中去找即可。無需在整個vue文件中翻山越嶺從computed模塊的代碼跳轉(zhuǎn)到function函數(shù)的代碼。