最近幾年，低代碼在產(chǎn)品開發(fā)過程中應用越來越廣泛；但還是有不少同學對此不了解。本文作者通過自身的經(jīng)歷，給大家分享了如何用低代碼完成設計，供大家參考。

啥是頁面設計器？

就像用 Axure 畫原型那樣簡單拖動幾個組件，然后再設置一下，就開發(fā)好了一個系統(tǒng)頁面，可以查看數(shù)據(jù)、操作數(shù)據(jù)、可以使用的、真正的頁面。

是的，這就是低代碼平臺中的頁面設計器，這我就好奇了，這樣的頁面設計器是怎么設計出來的呢？設計的思路與原則是怎樣的呢？

設計可以開發(fā)出頁面的設計器與一般系統(tǒng)的功能頁面可是不一樣的，后者相對而言是確定的，具體有哪些功能，有哪些交互，需要調(diào)用后端哪些接口，整體效果是可控的。而對于設計器頁面，設計出的最終頁面效果是用戶來確定的，怎么才能滿足用戶可以實現(xiàn)他的前端頁面交互、前后端數(shù)據(jù)交互呢？

一、臨危受命，準備干活！

當時，我們公司將產(chǎn)品定位于幫助業(yè)務人員和開發(fā)人員高效快速地開發(fā)出各種企業(yè)模板應用和各種復雜業(yè)務應用，解決各種定制化場景需求，這樣就必須要求設計器做到靈活性高、擴展性高，同時易用性也得高。

道理我都懂，確實很牛 X，如果是讓別人去設計，我肯定會說舞臺很大，好好表現(xiàn)。然而不幸的是，這個任務落到了我的身上，哈哈哈=-=

真的是讓人頭大，作為剛剛接觸到低代碼平臺的小白，不說無從下手吧，也可以說讓人摸不到頭腦！

冷靜了一陣子后，想了想，事情還是得做呀！

二、投石問路，競品分析！

作為一個產(chǎn)品人，遇上毫無頭緒的需求，第一反應是干嘛？那必須得是競品分析呀！

是的，我立馬找了市面上為數(shù)不多的低代碼平臺，準備仔仔細細地琢磨琢磨，當時的低代碼平臺都比較簡單，上手都很快，差不多一天時間就研究得七七八八了并做了詳細的分析記錄。

可是做完競品后，內(nèi)心有一點小小的失望，發(fā)現(xiàn)低代碼平臺產(chǎn)品與自己預想中的差異有點大，市面上的低代碼平臺主要以表單、表格驅(qū)動為主，集成封裝程度較高，雖然可以滿足一般的數(shù)據(jù)增刪改查和簡單的業(yè)務流程，但是很難滿足復雜業(yè)務應用各種定制化的需求，更不用說面向 C端用戶的應用頁面。不過也是，畢竟當時低代碼平臺的概念在國內(nèi)也才剛剛興起。

后來仔細一想，這反而是一件好事，說明我們的想法別人還沒有嘗試過，這條路說不定舞臺真的很大！

三、此路不通，另辟蹊徑！

競品分析效果不是很好，我決定換一種方式了，設計器不就是要設計出各種復雜的應用頁面嗎？我研究一下復雜的業(yè)務應用中有哪些頁面，哪些功能不就 OK 了嗎。

想到就去做，我立馬找了市面上主流的一些 ERP、CRM 、OA 等企業(yè)內(nèi)部管理系統(tǒng)，主要研究系統(tǒng)中的核心功能頁面，看能不能從這種復雜的頁面中找到一些共性，包括頁面中的主要部件、頁面交互、接口調(diào)用等等。

你還別說，你還真別說，研究了一段時間后，還真的有所收獲，最后大言不慚地說了一句：好像也不過如此，沒有那么復雜嘛=-=

下面詳細分享一下當時的分析和設計思路，開始我的表演。

因為時間有點久遠了，中間也迭代了多次想法，這里就不用最原始分析的資料，我在阿里云和釘釘后臺分別找了兩張頁面截圖，借此說明當時的分析思路。

首先來看第一張阿里云控制臺中的云服務器概覽功能頁面。

這種頁面結(jié)構(gòu)在 B 端系統(tǒng)中是十分常見的，也極具有代表性。頁面是由不同的區(qū)塊組成的，我在圖片上用數(shù)字標注了不同的區(qū)塊，每個區(qū)塊之間相對獨立，但彼此又有聯(lián)系，有的是交互上的聯(lián)系：

• 比如區(qū)塊 ② 是一個標簽頁，切換不同的標簽下面顯示不同內(nèi)容，區(qū)塊 ③ 是一個列表，點擊不同的列表項，右側(cè)顯示不同的內(nèi)容 ；
• 有的是數(shù)據(jù)傳遞上的聯(lián)系，比如區(qū)塊 ④ 是日期查詢， 執(zhí)行查詢后區(qū)塊 ⑤ 顯示滿足條件的統(tǒng)計數(shù)據(jù)；
• 當然我們多研究一點頁面就會發(fā)現(xiàn)，交互聯(lián)系和數(shù)據(jù)傳遞聯(lián)系是可以同時存在的，而且在大多數(shù)場景中，這兩者是同時存在的；
• 區(qū)塊④ 上面的靜態(tài)文本雖然我沒有用數(shù)字標準，其實也可以作為一個區(qū)塊；
• 但是區(qū)塊 ① 有點特殊，它是系統(tǒng)功能導航，一般 B 端系統(tǒng)里都有功能導航框架，有左側(cè)的，有頂部，有 L 型的等等，所以嚴格意義上說它并不屬于頁面的一部分，我們可以單獨提出一個概念來表達它，這里不詳細展開，后續(xù)可以專門寫一篇文章，這里面也大有門道哦。

經(jīng)過上面的一分析，我們再回過頭來看并總結(jié)一下：這個頁面就是由幾個區(qū)塊組成的，區(qū)塊之間可以點擊交互、可以數(shù)據(jù)傳遞。

一句話就概括了，沒有錯，就是這么簡單。

可能有人要說了，這個區(qū)塊里面的功能你都沒有分析呢，你就說簡單？

好像說的也啥毛病=-=，但我們從頁面頂層設計時，可以先忽略局部細節(jié)問題，這就好像高中學物理受力分析時，先用整體分析法，忽略物體內(nèi)部作用力，得到整體受力結(jié)果后，再分析單個物體，這里面的設計思想應該是相通的，所以后面再討論區(qū)塊里面的功能問題。

好了，有了頁面的整體結(jié)構(gòu)后，再看第二張圖，是不是就容易理解多了，這里就不再做重復分析了。

四、大刀闊斧，準備開干！

由上面的分析得到了結(jié)論：這個頁面就是由幾個區(qū)塊組成的，區(qū)塊之間可以點擊交互、可以數(shù)據(jù)傳遞。到這里就必須正視區(qū)塊了，區(qū)塊到底是什么？我們應該怎么定義它？我們先看區(qū)塊有哪些特點：

1. 會顯示在頁面上；
2. 會有特定的功能，比如多標簽切換、表格展示數(shù)據(jù)、篩選數(shù)據(jù)等等，反正是為了解決特定場景功能；
3. 可以點擊；
4. 會輸出數(shù)據(jù)；
5. 可以接受數(shù)據(jù)。

當然不是區(qū)塊必須同時這些功能，有些區(qū)塊可能只有其中一部分功能。

到這里，我覺得用“區(qū)塊”來表達已經(jīng)不是很貼切了，所以急需換一個更合理、更好理解、更通用的概念，“組件”應運而生！?。?/p>

為了更合理地表達，給組件加一個概念定義：

組件是將頁面中的可重用部分抽象為獨立的、功能完備且具有自我樣式和行為、支持輸入與輸出的單元。

1. 組件屬性配置

首先要明確一點，組件是為了解決特定場景需求的，所以在組件內(nèi)部會封裝一定的功能，比如表格組件會展示數(shù)據(jù)、支持分頁、添加按鈕等，篩選器組件支持設置篩選字段，篩選方式等等，同時為了給用戶絕對的靈活性，需要提供豐富的配置項。

組件本身功能可以通過內(nèi)部封裝加配置項的方式來解決，那怎么解決組件之間的交互聯(lián)動和數(shù)據(jù)傳遞聯(lián)動呢？這是一個問題，這不禁讓我想起了在網(wǎng)絡被發(fā)明之前，計算機都只是獨立的個體，并不能直接完成資源共享，有了網(wǎng)絡之后才算真正地進入計算機時代！

2. 前端組件聯(lián)動

當我在考慮組件之間的聯(lián)動問題時，不由得想到面向?qū)ο缶幊趟枷胫械摹邦悺保邦悺辈粌H相對獨立，“類”與“類”之間還可以相互調(diào)用、進行數(shù)據(jù)傳遞。我們一起來看下“類”有哪些特性：

• 成員變量，類內(nèi)部定義的變量，可以定義私有、公有；
• 構(gòu)造函數(shù)，默認無參 ，可以定義有參構(gòu)造函數(shù)，在創(chuàng)建類實例對象時使用；
• 成員/靜態(tài)函數(shù)，類實例或類調(diào)用，復雜具體的邏輯，函數(shù)內(nèi)部可以使用類成員變量、可以利用函數(shù)對外輸出類的成員變量。

借鑒“類”的特性，于是，我們可以對組件有以下的定義：

• 組件變量：組件內(nèi)部運行時對處理數(shù)據(jù)的變量，類比于“類”的成員變量；
• 組件函數(shù)：運行組件的入口，組件函數(shù)可以定為攜帶參數(shù)，也可以攜帶參數(shù)，類比于“類”的構(gòu)造函數(shù)；
• 組件事件：組件運行時的點擊對外輸出的事件，可以通過組件事件對外輸出組件變量，類比于“類”的成員函數(shù)。

每個組件的開發(fā)者，需要定義組件的組件變量、組件函數(shù)、組件事件，當然這三者不是必須同時存在，某些特性在一些組件中可以沒有。

這樣就可以做到組件聯(lián)動了嗎？怎么說得云里霧里的。

是的，是可以的，舉一個跟上面阿里云控制頁面差不多的功能場景：輸入日期篩選后，下面的表格顯示滿足條件的數(shù)據(jù)

我們做一下需求分析，在頁面需要一個篩選器組件（用于篩選）和一個表格組件（用于展示數(shù)據(jù)），篩選器組件和表格組件定義的組件的屬性見下表：

我們用一句簡單的語句就可以實現(xiàn)這個需求了：在篩選器組件的組件事件（執(zhí)行查詢后）添加語句：

表格組件.刷新表格（篩選器組件.篩選條件）

OK 了，簡單吧！

這樣， 在實現(xiàn)組件自身的功能的同時定義好每個組件的組件變量、組件函數(shù)、組件事件，這樣可以達到組件之間可以任意組合，組件交互聯(lián)動，數(shù)據(jù)聯(lián)動也不在話下！

基于上面的機制，我們開發(fā)一個稍微復雜一點的訂單管理功能，功能特性有：

• 支持按訂單的金額、下單時間、訂單編號等篩選訂單明細
• 統(tǒng)計每日訂單消費金額、每月匯總訂單消費金額
• 展示訂單明細，支持新增訂單、編輯訂單、查看訂單詳情、刪除訂單。
• 篩選、統(tǒng)計、訂單明細之間要相互聯(lián)動，包括新增/編輯/刪除訂單也是刷新訂單明細和統(tǒng)計。

具體效果可以查看下圖

看著有點復雜功能，其實我們利用幾個組件和幾句語句就開發(fā)好了，展示部分截圖

當然上面使用的都是一些簡單的語句，后來隨著功能的擴展，類比于一般的編程語言，我們逐步加入了條件判斷語句、循環(huán)判斷語句、聲明變量語句等等，可以看下圖簡單了解一下，這里就不詳細展開。

3. 前后端數(shù)據(jù)聯(lián)動

有細心的小伙伴可能已經(jīng)發(fā)現(xiàn)了，你上面的一頓分析都是前端組件之前的聯(lián)動，如果前端需要調(diào)用后端某個接口怎么處理呢，比如我在表格組件中添加了一個按鈕，這個按鈕需要執(zhí)行后端接口的邏輯，那又怎么實現(xiàn)呢？

這是一個好問題，首先我們在實現(xiàn)某些組件時會封裝調(diào)用特定的后端接口，比如表格組件展示數(shù)據(jù)，我們會調(diào)用查詢數(shù)據(jù)接口，表單提交數(shù)據(jù)會調(diào)用新增數(shù)據(jù)接口，但是這解決不了前端調(diào)用用戶自己編寫的接口。

這個過程中我們想了很多辦法，比如前端事件觸發(fā)后臺工作流？專門開發(fā)一個前端組件調(diào)用后端接口？利用數(shù)據(jù)表事件、定時任務變相地解決這個問題？等等方案，但不是很優(yōu)雅，不是很符合我們編程語言中的使用習慣

后來我們將用戶自己編寫的后端接口放在服務下，就像傳統(tǒng)編程語言中編寫某個類下的函數(shù)一樣，前端組件調(diào)用后端接口就按照執(zhí)行指定的格式調(diào)用就好。

比如 XX 服務.XX 函數(shù)，可以看下圖中的語句

這個設計也是經(jīng)歷過很長的積淀才形成的，完美而優(yōu)雅，這里就不再詳細分析了，后續(xù)專門出一篇文章介紹，這個過程也是美妙又有趣的！

在服務下編寫后端接口：

五、略微小結(jié)

至此，我們很完美地完成這項任務，設計出了一個靈活性強、易用性高的前端頁面設計器，文章寫出來看著輕松，可是其中的過程卻是異常艱辛，中間走了不少彎路，試了不少錯，幸運的是，結(jié)果是好的。在這次設計過程中，我也總結(jié)了幾點設計經(jīng)驗與大家分享：

• 分析問題本身，探索問題本質(zhì)，透過現(xiàn)象看本質(zhì)；
• 先頂層設計，再考慮細節(jié)；
• 經(jīng)典永不過時，多向經(jīng)典的編程思想借鑒學習，設計思想都是互通的；
• 不斷迭代、不斷否定，追尋問題的最優(yōu)解。

以上就是我的分享，如果你對低代碼或者產(chǎn)品設計感興趣，可以在評論留言或者私我，我們下一期再見。