導語 | 從去年開始，我們團隊一直在研發一款叫做“無極”的低代碼産品。元件是低代碼平台可視化布局的基礎元素。作為低代碼平台方，既要提供公共元件池，直接覆寫90%的元件場景；又要有靈活易用的元件開發方案，供多個業務開發自定義元件。下文我們将分享平台級元件相關的一些設計思路。
作者：katecjzheng 騰訊PCG前端工程師
背景
我們在研發的是一個to B的低代碼平台。簡單來說，就是利用可視化的方式，通過拖拽元件到畫布中，結合資料源的綁定，用來生成管理台的工具。
實際上，管理台的模式相對固定，有大量同質化需求，套用低代碼去實作最為合适。對于畫布來說，組成UI的元件庫就最為關鍵。目前我們提供了40個官方公共元件，能滿足大部分管理台需求。
但業務方一定有定制化元件需求。而隻要自定義元件的生産門檻有一點高，就會勸退使用方，甚至直接不使用整個平台。最理想的模式應該是，整個畫布大塊（甚至全部）的區域，能直接使用公共元件拖拽生成；而其中一些塊，能夠用自定義元件進行填充。既能完整地還原頁面需求，又能減少重複開發工作（主要指平台的公共元件、接口調用、平台權限等），最大化獲得使用低代碼平台帶來的收益。
而對于一個自定義元件，必須足夠靈活。元件開發者可以選擇将元件共享出來，供其他團隊搭建管理台時直接使用。或者作為一個原子，供其他自定義元件套娃依賴使用。并且，元件最好跟項目互相獨立，這樣任意一個元件可支援跨項目進行複用。
對于低代碼平台元件的設計，最關注以下兩點：
1. 元件開發流程
目标：對齊原生元件開發體驗，所見即所得。指的是，不需要釋出元件後，才能看到元件在多個遠端管理台多種場景的呈現效果。當然了，也不能出現太多"個性化"概念讓開發者去了解（比如如何引用自定義元件，自定義屬性面闆等）。
2. 元件依賴管理
管理台中涉及大量元件包含元件的場景，是以會聊到元件線上上的版本政策問題。
平台級元件開發方式
1. 元件的基本構成
一個完整的元件，由元件本身的UI，以及屬性面闆構成。調試時兩者需要關聯，需要在元件UI上，實時看到對應的屬性配置效果。
屬性面闆一般涉及到資料源、管理台頁面等的綁定，需要跟平台功能互通。如考慮最最傳統的元件開發模式：不提供宿主環境，直接開發一個元件，釋出到平台使用。
總結：元件脫離平台進行開發，需要反複釋出、線上驗證才能達到預期效果。
2. 傳統的元件開發模式 - 進階版
那讓使用者直接使用平台代碼進行開發，這樣就有宿主環境了。
第一步，拉取平台代碼
第二步，偷偷問平台管理者拿賬号密碼（平台級賬号密碼是保密的，不在代碼中）
第三步，一翻折騰後把整個平台代碼跑起來，終于想起來是為了開發一個小元件（這才是關鍵啊喂）...
作為一個平台方工具，DB資訊，一般隻會由私有部署的管理者進行管理，不可能開放給普通使用者使用。而且，平台代碼由平台方進行維護，本地把平台代碼拉取下來進行開發，就得關注平台自身代碼的更新情況，不然無法保證絕對仿真性。
換個思路，隻base拖拽生成的管理台代碼進行開發，在我們無極平台上也無法成立。主要因為平台的頁面産物是資料配置（布局格式是一種類似jsonSchema的協定），沒有代碼，更無法在這個基礎上進行元件開發。
3. 平台級元件開發模式
既然要搭建一個一模一樣的平台進行開發如此困難，我們能不能直接使用遠端管理台進行開發呢？無極實作的元件開發流程分為以下幾步：
主要原理是，通過打通本地和遠端管理台的連接配接，讓開發者不需要了解平台代碼，隻關注自身元件代碼就可以了。做到跟vue元件原生元件開發體驗一模一樣，并且因為直接複用了真實的宿主環境，達到最大仿真性。
分享一下這套流程的實作思路。
遠端管理台分為生産模式和開發模式。CLI工具會收集本地倉庫的元件開發清單，提供接口給遠端管理台拉取。開發模式下，元件的加載政策是，本地元件優先從localhost加載；遠端元件則直接從元件的cdn位址加載。這樣就實作了本地自定義元件與線上元件線上上布局中混排。
剛談到遠端管理台加載了本地元件JS，實際上，這個本地元件JS會注入websocket用戶端和HMR更新子產品的代碼，當本地代碼發生變更，本地CLI的websocket會與遠端管理台通信。HMR子產品會請求最新的元件JS，并控制DOM節點的更新（無極參考了開源倉庫 webpack-hot-client 的思想進行了改造，大緻思路兩者基本對齊）。
我們來示範一下最終HMR達到的效果：
這樣，可以在多個線上管理台上，實時看到元件修改後的效果。并且跟原生的vue元件開發方式，毫無差異。
3. 元件批量開發
方案灰階使用時，當單個倉庫10+個元件同時開發時，啟動指令首次建構時，在單程序中暴露出性能問題。于是我們的思路是改單程序的串行為多進行的并行執行，每個元件獨立子程序進行建構，達到最小化耗時。并且由主程序進行socket連接配接的分發，最終隻占用了一個端口。此時建構中間件主要由以下幾步構成：
1、worker程序池，一個子程序維護一個元件的建構服務
2、master程序，維護元件資訊池以及socket server池
3、由master程序，統一對遠端管理台頁面進行消息通信
我們來看看最終的優化效果：
小結，無極目前的元件開發模式，通過複用真實的管理台，最大程度地降低了元件開發的成本。我們相信隻有提高開發效率，才能讓元件開發者更好地參與到元件生态的共建中，從中孵化出高品質元件。
元件依賴管理
1. 背景
無極是to B的，涉及到大量元件包含元件的場景，例如清單元件和複雜表單元件（一個複雜表單元件會包含輸入框、圖檔、按鈕等）。對于無極平台，元件依賴以及元件的線上版本政策，是很重要的一環。
2. 元件的建構方式 - 鎖版本 pk 不鎖版本
舉一個例子來表述問題吧。假設元件A依賴文本輸入框元件。
一般會有兩種建構方式：
一種是bundle的打包方式，就是鎖版本。也就是說，将輸入框元件打包進元件A中。
這個方案最大的優點是元件是自治的，輸入框元件的版本維護由元件A自行處理，沒有元件更新的風險。缺點是管理台中如果也使用了文本輸入框，就會存在兩個文本輸入框版本，可能會導緻樣式不一緻等問題。并且，會增加元件的JS打包體積（例如，柱形圖和餅圖，都依賴了echarts元件，把echarts元件各自打包進兩個元件中，是不是有點可怕？）。
另一種是類似AMD異步子產品加載的方式，也就是動态依賴。假設元件B也依賴了文本輸入框，他們内部隻會聲明自己的依賴鍊，不會把輸入框元件打包進自己的JS中，最後加載的輸入框元件JS會指向同一個。這種做法的好處是元件是解耦的，輸入框元件可以快速更新，全局隻需要維護一個輸入框元件即可。當然，全局更新也是有風險的，它有向下相容以及穩定性的問題。
實際上，bundle方式在to C場景中使用最多，它的穩定性最好。to C的h5元件一般互相獨立，不涉及複雜依賴鍊，隻求穩定。這時，公共庫的版本是鎖定的，通常是需求需要新功能或者有bug時，開發者才會手動進行某個元件的版本更新。
而無極作為一個to B平台，有大量元件複雜依賴的場景，比較适合動态依賴的方式。平台不可能逐個通知多個業務方，去進行更新，并且舊版本元件不可能進行持續維護，大量元件逐個更新十分麻煩。于是我們選擇動态依賴的方式，直接把線上運作時版本去掉了，也就是線上隻有一個唯一版本，就像小程式一樣。
而對于全局更新帶來的風險，目前隻有官方元件有大範圍依賴，這個風險可以由官方團隊用一些工程化的手段，例如單測、灰階（後面會提及）等，去保證向下相容。
3. 如何實作元件動态依賴？
我們不希望無極元件的依賴方式過于個性化，是以首先考慮對齊日常元件的引用模式。最後拍闆使用@wuji域作為公共依賴的标記，建構時會分析代碼中的@wuji域的加載，并改造建構産物。
整個建構流程分為以下幾步：
1、提取@wuji域的加載子產品，收集依賴
2、将依賴清單注入到全局元件加載器的注冊函數中。加載元件JS時，會先異步拉取依賴清單中的元件JS，将元件對象放在記憶體中
3、@wuji域的加載，會替換成全局元件加載器加載函數。元件加載器的require方法會從記憶體中擷取元件對象，接下來進行元件的執行個體化
元件的最終建構産物，因封裝了依賴鍊加載邏輯，會比較特殊。但對元件開發者是無感的，我們隻需要關注開發者的開發流程體驗即可。
4. 元件配套的多環境
目前平台為每個元件提供了測試環境、灰階環境（開發中）、生産環境。各個環境是這樣設計的：
1、測試環境。私有部署可以單獨部署一套服務，将全部元件指向測試環境，進行統一的預釋出驗證
2、灰階環境。以項目為粒度，可以配置某個項目使用某個元件的灰階版本，待驗證後，再由開發者将灰階版本轉為正式版本
3、生産環境。線上使用的唯一版本。每個元件都有維護自己的版本清單，可快速復原至任意版本。
通過多環境進行驗證，可以有效提高元件全局更新的可控度。
元件生态的共建
無極是一個平台，會有多個業務的私有部署。公共元件統一由官方源進行元件資訊的存儲，而設計元件存儲的時候，我們會将私有部署了解成一個源，一個源裡面會有多個自定義元件，自定義元件會由自己的組别進行分類。
由上圖可以看出，私有部署間的元件是存儲在各自源内，無法進行跨源共享。如果單個業務方有優秀的公共元件需要分享，可以提MR到官方團隊的公共元件庫，最終也能分享到多個私有部署進行使用。
最後
總結一下無極低平台的元件方案，目前做到以下幾點：
1、通過複用真實宿主環境開發，簡化開發調試流程
2、元件托管，快捷一鍵釋出到線上開發環境
3、配套的多環境驗證
4、運作時自動依賴分析，元件全局唯一版本，減少版本對元件開發者帶來的複雜度
希望能通過這些細點，讓整個開發流程、使用流程更爽，打造一個圍繞元件的良性生态圈。對于整個低代碼平台來說，也是後續可持續營運和有足夠擴充性的基礎保障。
如果大家有好的想法，歡迎交流。
# 研發效能新書推薦 #
#《有料程式員》直播 #
對談極限運動算法工程師：與代碼和戶外運動的熱愛與緣分
關注視訊号，預約直播👇
點個關注，我們下期再見👋