視覺化搭建的一些思考和實踐

傳統前端業務開發中，元件角色定位、演化

在傳統Web開發過程中，前端專案的技術架構方式大概分為幾個步驟，一般我們先確定一個基礎的技術選型，比如Vue或者React，隨後，我們會選擇功能元件庫，比如ElementUI或者antDesign，之後再根據業務需要，二次封裝一些定製化的業務元件，這基本上就完成了我們對中後臺系統的技術結構搭建。

隨後，在不斷的業務開發過程中，我們再根據實際需要，抽象一些公共區塊模組，經過日積月累，透過這些業務區塊元件，我們就可以快速的去搭建一個新頁面，從而極大的提升團隊的開發效率。

但是，在這種場景下，我們仍然不可避免的，需要主動去建立新的頁面，這個過程鏈路依舊很長，針對這種情況，我們就需要考慮有沒有更優雅的方式，將這種開發流程狀態進行抽象，規則化，從而減少這種頁面重複搭建過程。

元件化的一些侷限性

1. 針對部分團隊，前端專案非常多的情況，我們依然需要對每個前端工程單獨引入業務元件，這個過程本身也會造成效率的低下。
2. 針對一些複雜系統或者跨部門開發，多個系統之間的頁面，也可能會共享業務元件，這就不可避免的會帶來溝通和研發成本的提升，甚至在很多時候，我們不得不去在團隊時間中做出一些妥協和共識，才能實現業務開發。
3. 我現在一部分的工作會來自不同的公司、行業，在跨行業、跨公司主體或者第三方社群時，我們也缺乏一種規則來實現不同主體之間的高效的流通。

低/無程式碼的充要條件

1. 元件的流通：目前針對元件的流通，我們缺乏跨主體的一些協議，比如物料元件的生產、消費、管理、二次封裝、編排等等。
2. 豐富的物料庫：基於業務元件的物料庫是低程式碼平臺必備的環節。
3. 編排：編排的主要能力，是為了方便開發者輕鬆設計、製作、配置業務元件。
4. 渲染器：當我們的業務開發者開發完畢一個頁面，我們需要提供一種方式讓使用者去預覽或者釋出，這就需要一個渲染器將我們生成的程式碼進行頁面渲染、展現。
5. 出碼模組：基於低程式碼平臺開發完一個專案後，我們需要交付原始碼包或者專案，方便我們的開發者進行生產部署或者二次開發。

低程式碼的一些侷限性

低程式碼是需要業務、產品、技術等等，多方之間進行一定量的妥協，我們只能解決30%~60%的業務場景，最終的效果仍然需要進行業務驗證。

低程式碼實踐-H5-Dooring

H5-dooring是去年下半年，開源的一個低程式碼平臺，主要的目的是方便使用者快速搭建一個簡單的低程式碼專案，從2020年下半年至今，Github上已經有4500+stars，同時有50+家企業、1000+使用者基於H5-dooring生成頁面。

低程式碼互動的三大實現思路

第一種是釘釘宜搭採用的這種自然流佈局方式，它的優點在於這種開發方式更貼合我們傳統的開發流程，它的配置靈活度也非常高，並且也更容易去做適配，但相對來說開發門檻略高，對沒有技術開發經驗的小白開發者不太友好。

第二種是我們H5-Dooring採用的這種智慧網格佈局方案，它的優勢是我們開發者可以去透過拖拽來更輕鬆的搭建一個元件、頁面，但缺點就是無法去對一些更復雜的層級元件進行實現，比如圖層或者圖片之間的疊加，或者對多個元件之間的靈活度，有著非常高要求的場景。

最後一種就是自由佈局方案，自由佈局是現在很多lowcode平臺普遍採用的方案，比如易企秀、魯班、位元組魔方等等，它的好處顯而易見，對有著自定義需求的業務場景，它的支援顆粒度非常友好。

H5-Dooring整體架構簡介

H5-Dooring的整個架構主要包括以下幾個模組：物料庫、佈局畫布、屬性皮膚、功能皮膚，以及一些其他的擴充能力。

渲染方面：H5-Dooring的頁面渲染是基於schema資訊，動態進行元件的渲染，佈局方式主要是利用schema中，元件的位置資訊來動態計算網格位置，從而渲染出整個頁面。另外元件的載入，也是基於schema元件資訊按需進行載入，所以針對一個複雜頁面的渲染，它的載入速度也不會很慢。

屬性皮膚、表單設計：H5-Dooring的屬性配置採用動態配置皮膚，內部基於一套DSL規則進行實現、解析，支援靈活的屬性設定。另外，我們也封裝很多常用的表單元件，支援開發者快速進行頁面搭建。

動態資料來源設計：現在很多低程式碼平臺的資料來源設計採用的都是靜態設定，比如多個業務元件使用同一個資料來源，往往是進行多份資料的複製，之間不再產生關聯。H5-Dooring支援動態資料來源設計，這意味著我們可以在生產環境下動態去載入資料，從而進行資料更新、替換。

出碼模組：目前H5-Dooring支援構建出Dist包和原始碼包，背後的實現是基於我們的基座工程，它允許我們的使用者，線上生成Dist工程和原始碼工程的Zip包，並提供下載。

視覺化搭建的未來展望

第一點是搭建引擎最佳化，從而能夠去支援我們做更多功能的擴充套件、以及豐富業務元件物料，以來滿足更多的應用場景。

第二點是離線化，很多公司受限於各種網路問題，需要一些本地離線化開發，我們後期可能會透過Electron這樣的能力去進行實現。

第三點是加強元件之間聯絡的動作系統，以支援我們業務元件的互動跟協作。

第四點是我們監控系統的智慧化搭建，我們可以透過對使用者操作、使用者資料的反饋系統，分析出一個使用者他自己的偏好，然後動態透過一些個性化服務能力。

最後一點是跨端的需求，這種需求也是現在很多前端專案的剛性需求，我們也會去設想一些實現方案。