微信小程序提供了一套完整而又優(yōu)美的組件庫(kù)，里面包含了豐富的組件，并且可以進(jìn)行多端的兼容，無(wú)論是在小程序端還是 H5 端都可以使用它進(jìn)行組件的開(kāi)發(fā)。本文將會(huì)對(duì)小程序組件庫(kù)進(jìn)行詳細(xì)的介紹。

小程序組件庫(kù)由來(lái)

傳統(tǒng)開(kāi)發(fā)方式效率低、維護(hù)成本高，而且往往隨著業(yè)務(wù)的增長(zhǎng)或者變更，系統(tǒng)的復(fù)雜度會(huì)呈現(xiàn)指數(shù)級(jí)的增長(zhǎng)，經(jīng)常出現(xiàn)的情況就是一個(gè)小小的改動(dòng)或者一個(gè)小功能的增加可能會(huì)引起整體邏輯的修改，造成牽一發(fā)而動(dòng)全身。

同時(shí)，不同的開(kāi)發(fā)人員有各自的開(kāi)發(fā)習(xí)慣和風(fēng)格，導(dǎo)致代碼的交互方法和頁(yè)面的風(fēng)格各不相同，這樣就導(dǎo)致不同的開(kāi)發(fā)人員沒(méi)有統(tǒng)一的規(guī)范，代碼變得冗余，復(fù)用率低等各種問(wèn)題越來(lái)越明顯。

為了實(shí)現(xiàn)提高代碼復(fù)用率，統(tǒng)一視覺(jué)和交互，并且規(guī)范開(kāi)發(fā)，小程序組件庫(kù)應(yīng)運(yùn)而生。

多端兼容

起初設(shè)計(jì)時(shí)，為了使小程序組件庫(kù)能夠滿足能在小程序和 H5 兩個(gè)平臺(tái)上使用，我們搭建了兩套組件庫(kù)，采用多倉(cāng)庫(kù)設(shè)計(jì)，一套適用于 H5 開(kāi)發(fā)，一套適用于 App 小程序開(kāi)發(fā)，如圖所示：

這種模式在組件庫(kù)內(nèi)容較少的時(shí)候工作得還不錯(cuò)，但是隨著后續(xù)支持的組件越來(lái)越多，兩套代碼所帶來(lái)的問(wèn)題也愈發(fā)突出：即使一個(gè)簡(jiǎn)單的需求也需要在兩套代碼庫(kù)分別修改，造成額外的工作量，效率低下。因此，我們開(kāi)始考慮，是否有更好的方式能夠只寫一份代碼，又同時(shí)支持小程序和 H5 呢？

要合并代碼，我們必須分析出兩條代碼的相同點(diǎn)和不同點(diǎn)，把相同點(diǎn)提取為公共的代碼，同時(shí)對(duì)不同點(diǎn)想辦法針對(duì)小程序和 H5 的要求分別處理。

我們組件庫(kù)都是基于 Vue（針對(duì) H5）/類 Vue（針對(duì)小程序）的方式實(shí)現(xiàn)，因此一個(gè)組件的代碼，都是由模板（template）、樣式（style）、邏輯（script）三個(gè)部分組成。從外觀上說(shuō)，H5 和小程序的組件是保持高度一致的，因此，模板和樣式部分完全可以復(fù)用，只要保證基礎(chǔ)構(gòu)成和屬性一即可。

唯一的區(qū)別聚焦在邏輯上：對(duì)于 H5 組件，邏輯處理相對(duì)比較簡(jiǎn)單，基本只有交互邏輯；而對(duì)于小程序組件庫(kù)而言，還需要處理跟小程序框架相關(guān)的控制邏輯，例如：通過(guò) jsbridge 與原生層完成生命周期協(xié)同控制，又或者在部分邏輯實(shí)現(xiàn)上需要使用原生層的 API 完成。如圖所示：

通過(guò)對(duì)目前市場(chǎng)上成熟的多端輸出組件庫(kù)進(jìn)行調(diào)研后，得出了兩個(gè)初步的方案：

1. 運(yùn)行時(shí)抹平差異方案：它是先以 JavaScript 作為基礎(chǔ)選定一個(gè) DSL 框架，以這個(gè) DSL 框架為標(biāo)準(zhǔn)在各端分別編譯為不同的代碼，各端分別有一個(gè)運(yùn)行時(shí)框架或兼容組件庫(kù)保證代碼正確運(yùn)行。

2. 條件編譯型方案：通過(guò)對(duì)代碼的不兼容邏輯部分進(jìn)行條件判斷，通過(guò)在打包時(shí)添加全局變量的方式，在不同的條件下執(zhí)行對(duì)應(yīng)的邏輯部分，從而實(shí)現(xiàn)不同端打包編譯不同代碼庫(kù)。

根據(jù)目前的需求多端只需要輸出小程序組件庫(kù)和 H5 兩個(gè)組件庫(kù)，而且運(yùn)行時(shí)抹平差異方案比較復(fù)雜，首先需要基于同樣的 DSL 設(shè)計(jì)一套統(tǒng)一的 API，然后需要分別針對(duì) H5 和小程序?qū)崿F(xiàn)兩套 runtime 來(lái)屏蔽底層差異，投入成本比較高。

綜合對(duì)比下來(lái)，我們采用了條件編譯型方案來(lái)實(shí)現(xiàn)多端的需求。

采用條件編譯這個(gè)方案，我們可以復(fù)用代碼的模板部分和樣式部分，只需要在所有不可復(fù)用的邏輯交互部分加上條件判斷。條件判斷的添加方式如下圖所示：

接下來(lái)，我們需要在打包時(shí)添加環(huán)境變量，實(shí)現(xiàn)通過(guò)不同的打包命令得到不同的組件庫(kù)。因此 cross-env 這個(gè)模塊是一個(gè)很好的選擇，它可以在打包命令處設(shè)置全局環(huán)境變量。打包命令的設(shè)置如下圖所示：

然后執(zhí)行打包命令時(shí)就會(huì)將特定的環(huán)境變量打包到代碼，在使用組件庫(kù)時(shí)通過(guò)不同的條件去執(zhí)行不同的邏輯部分，從而實(shí)現(xiàn)組件庫(kù)的多端兼容，流程圖如下所示：

未來(lái)展望

隨著小程序庫(kù)的使用越來(lái)越廣泛，我們可能會(huì)不僅僅只兼容小程序和 H5 這兩端，還會(huì)對(duì)支付寶小程序端，微信小程序端等進(jìn)行兼容，就像 uni-app 組件庫(kù)一樣支持各種各樣的端。

到時(shí)候，目前條件編譯的兼容方案可能無(wú)法支持我們小程序的發(fā)展，我們可能會(huì)選擇采用運(yùn)行時(shí)抹平差異方案，自己搭建一套框架去管理各個(gè)端的組件庫(kù)，這樣就可以讓每個(gè)端的小程序代碼很干凈，各自都只有自己的邏輯交互，我們只需要通過(guò)外部框架去管理消除每個(gè)端的小程序庫(kù)的差異即可。通過(guò)這種方案就可以更加優(yōu)雅和完美的去實(shí)現(xiàn)組件庫(kù)多端兼容的問(wèn)題。