文：清凌渡 題拍拍前端開發專家

中後臺應用主要用於資訊的查詢、展示和修改，並把資料變更持久化到資料庫中，可以看作傳統資料管理平臺的延伸。產品形態可以被收斂為 UI 模式一致的標準化元件庫，比如 Ant Design、AntV 等通用 UI 庫是中後臺產品前端開發的事實標準。

在低程式碼平臺中，所見即所得的組裝中後臺應用，代替純手工的程式碼編寫，可以大幅提升開發的效率和質量。

基於業界優秀的前端基礎元件，進行低程式碼平臺的開發，成本和難度基本可控，其關鍵工作是低程式碼平臺底層規範的設計，即實現低程式碼平臺的領域專用語言（下面簡稱“DSL”）。

一、應用解構

如下圖所示，一箇中後臺應用主要有表單頁、列表頁、詳情頁 3 種頁面形態，粗粒度總結如下：

表單頁面主要包含表單元件和選擇元件兩種；

列表元件主要包含過濾元件、表格元件、分頁元件 3 種，其中表格元件可以包含單元格元件。

詳情頁面主要包含列表元件和圖表元件。

在典型的中後臺開發過程中，前端工程師的工作可以分為應用的靜態組織部分和狀態的動態轉移部分兩大類。

如上圖所示，中後臺應用的組織結構，是一棵典型的樹形結構：

應用組織結構由應用、頁面、元件 3 層結構組合而成；

應用透過 Route Children 組織頁面，並且 Route Children 支援遞迴組織多層次路由，頁面支援遞迴組織多層 Layout 佈局；

頁面透過 Template 組織元件；

元件管理內部狀態的轉移和行為事件的響應，比如：

API 請求（GET），狀態 JSON 資料從服務端傳送到客戶端，建議透過配置在元件內部編碼完成；

API 上報（POST），狀態從客戶端表單資料上報到服務端，客戶端狀態生成的主要載體是表單元件，建議透過配置在元件內部編碼完成。

狀態轉移進一步串聯應用的整體功能，主要滿足頁面的跳轉：

引數傳遞（Params，如上圖中的 Route + Query），從列表頁面跳轉到詳情頁面。由 Route Params 來實現，即用 RESTful 風格，傳遞 ID 等關鍵引數，用 RESTful 風格的優勢如下。

低程式碼平臺的領域專用語言，即要支援完整的應用組織和狀態轉移，來完成應用的構建。整個應用的靜態結構組織透過搭建來進行配置是非常容易的，如何簡潔的完成動態的狀態轉移是低程式碼平臺易用性的關鍵，建議透過約定來完成：

低程式碼編輯器部分僅僅保留配置，不提供編碼支援；

複雜邏輯完全封裝到元件內部，低程式碼編輯器僅僅勾選配置配置或填寫靜態字串；

元件是低程式碼平臺的資產積累，也是前端工程師的專業領域。

二、設計思路

釘釘的宜搭、騰訊的雲開發低碼平臺等業界方案，都是私有協議。雖然私有協議的自主性看似更高，但如果初期設計不周全，後續的升級會被相容性嚴重拖垮。

另一種思路是基於“現成/開源”的領域專用語言之上，定義一份規範，即封裝開源協議。

從自主性、完備性、擴充套件性、易用性、ROI5 個方面，兩種思路對比如下圖：

本文基於 Vue SFC（單檔案元件）、Vue Compiler-Core、Vue-Router 的 Vue 通用全家桶，從中選擇需要的部分類定義進行規範化，來完成 DSL 的設計。這個思路最大的優勢是：和大家熟悉的 Vue 事實規範保持了一致，DSL 是一個新庫，也是一個 6 年的成熟專案。同時滿足了基本的向前相容性要求——當未來的對低程式碼平臺產生新的需要，只需要選擇另外一部分類定義進行規範化。

三、DSL 和 SDK 設計

一個完備的 DSL 定義（語義和語法）需要滿足應用組織和狀態轉移的訴求。DSL 核心元件和總體方案如下：

應用透過路由把頁面組織在一起，構成完整的應用，使用 Vue-Router 進行規範和描述。

頁面由元件組合（兄弟、巢狀兩種形式）而成，頁面中元件的宣告和關係使用 Vue Compiler-Core 進行規範和描述；

元件遵循 SFC 規範。

3。1 應用規範設計

應用規範如下圖所示，包含元資訊和路由結構 2 部分組成。

路由和頁面透過 PageID 外聯；

頁面透過路由傳遞狀態（資料）——整個應用中，可配置狀態的傳遞僅透過路由完成；

路由的層次雖然跟選單的層次是兩個相互獨立的資訊，為了簡化，可以把路由資訊作為選單資訊來使用。

3。2 頁面規範設計

頁面規範如下圖所示，主要包含元資訊和頁面結構兩部分，分為佈局頁面（比如主導航部分）和落地頁面（詳情部分、列表部分）兩種，佈局頁面頁面可以巢狀，落地頁面被包含在佈局頁面中。

3。3 元件規範

元件規範如下圖所示，需要遵循 Vue 的 SFC 規範，元資訊主要包含元件標識、屬性描述、規範版本 3 部分。

3。4 元件節點依賴關係

基於 Vue Compiler-Core，封裝瞭如下 7 類節點，其依賴關係如下：

每個 **NodeDSL 均對應一個 **Node 類，前者是 Plain Object、後者是編輯器程式中操作 DSL 的類，這 4 個基本類中均支援下面 4 個方法：

構造方法，引數為部分 DSL 格式的 Plain Object；

更新方法，引數為部分 DSL 格式的 Plain Object

序列化方法，返回相應 DSL 格式的 Plain object，用於資料庫的儲存；

反序列化方法，引數是完整 DSL 格式的 Plain Object，將當前物件例項進行更新，用於二次編輯。

3。5 示例程式碼

3。5。1 應用組裝示例

透過上面的 SDK，操作應用中 DSL 的程式碼如下所示：

import Application， { ApplicationDSL } from ‘。/Application’；import Route， { RouteDSL } from ‘。/Route’；import Page， { PageDSL } from ‘。/Page’；import ElementNode， { ElementNodeDSL } from ‘。/ElementNode’；const app = new Application（{}）；const page = new Page（{}）；const route = new Route（{meta： { pageId： page。meta。uuid， page： page }}）；app。routeInsertInto（route， undefined）；const component = new ElementNode（{ tag： ‘TheBothLayout’， propsScheme： { properties： { menus： { title： ‘選單’， type： ‘array’， default： ‘’， } }， }， }）；page。componentInsertInto（component， undefined）；

3.5.2 序列化後的結構示例

{ “meta”： { “name”： “”， “uuid”： “1fafcf93-99adb0b18564”， “specVersion”： “0。1。0” }， “body”： ［ { “children”： ［］， “meta”： { “uuid”： “a0eced40-ee12609d586e”， “pageId”： “0729c617-9f75e32f8fc4”， “specVersion”： “0。1。0” } } ］ }

四、進一步思考

低程式碼本質上是最佳實踐的模板化使用，如下圖所示，既是閉環內最佳實踐產品化的過程，也是外層產品對內層產品規模化複用和反饋的閉環：

標準流程是經驗的資產化——把前端工程師個體經驗總結、沉澱、統一為“標準件”、“中介軟體”產品，比如優秀的前端庫 Ant Design；

工具系統是標準的資本化——比如在低程式碼平臺中視覺化的組裝 Ant Design，大幅降低 App 生產的邊際成本；

資料智慧是工具的自動化——比如 imgcook（

https：//www。imgcook。com/

）由設計稿智慧生成程式碼。

從工程執行的角度，低程式碼的目標是提效，不是把前端工程師的工作量轉移給後端工程師、產品經理、測試老師等，而是和原有工作整合後的提效和提質——其本質是重複工作的標準化和自動化，把前端工程師從生產過程中下沉於基建和物料庫建設來支撐提效；或把高複雜度工作降低出錯的機率。

從使用者的視角，低程式碼有兩層含義：

更簡單的配置，而不是深奧程式碼的視覺化編寫：

複雜的程式碼封裝為元件，下沉到物料庫中——這應該是專業前端工程師把自身手藝總結為介面簡單的標準組件的生產過程，產出的元件在低程式碼編輯器中配置化使用；而不是在低程式碼編輯器中進行深奧的手藝總結；

更少量的配置，而不是複雜程式碼的視覺化重複：

重複的程式碼總結為標準，操作過程自動化——這應該是標準組件進一步模板化使用的過程；而不是重複的工作反覆點選滑鼠。

作者：清凌渡 題拍拍前端開發專家

出處：https：//mp。weixin。qq。com/s/jrTvj_slJWhj-TC2E_xKHQ

TAG: 元件頁面程式碼DSL應用