今天聊：除了頁面-低代碼也能夠快速生產組件

前端早早聊大會，與掘金聯合舉辦。加 codingdreamer 進大會技術羣，贏在新的起跑線。

---

第二十七屆|前端 Flutter 專場，瞭解 Web 渲染引擎|UI 框架|性能優化，6-5 下午直播，6 位講師(京東/滿幫/閒魚等)，點我上車👉 (報名地址)：

全部往期都有全程錄播，上手年票一次性解鎖所有

---

正文以下

本文是第十六屆 - 前端早早聊組件化專場，也是早早聊第 115 場，來自 1688-度城 的分享。

1、自我介紹

你們好，我是來自 CBU 體驗技術部度城。今天來給你們分享一下《如何用低代碼開發組件》。

2、前言

名詞解釋

首先來介紹一個概念低代碼。你們可能在一些其餘的渠道或者說在其餘的一些站點上面瞭解過，它並非一個很是新的一個概念，相反它是一個比較老的概念。所謂低代碼 LowCode 可理解爲它的代碼量會比較少一點。咱們在正常開發的時候，咱們大部分都是用的是源碼，即將全部邏輯代碼敲出來，可是咱們想但願用另一種方式把一部分代碼寫出來，一部分經過其餘方式來替代。源碼方式 ProCode，還有一種方式叫 NoCode 就是一點代碼都沒有，主要在一些搭建的場景，它不須要有代碼，就能夠把一個頁面或者說把一個組件搭出來。ProCode 就是咱們以前的源碼方式。

方案比較

這三者之間有什麼區別的？咱們把除了代碼之外的另一種開發的方式，咱們把它叫作可視化的開發方式。什麼叫可視化的開發方式呢？可視化就是除了代碼之外的 UI 視圖設置、GUI 的配置、產品化的配置方案、一些細節的高效抽象等。咱們把代碼跟可視化設成兩個比例：

• NoCode 所有都是可視化，沒有任何一行代碼；
• ProCode 所有都是代碼；
• LowCode 一部分是代碼，一部分是可視化，可同時兼顧效率和靈活性。

這裏有這樣一個箭頭，從上到下來講：

• NoCode 效率上是最高的，由於不須要去寫代碼，可能去採用一些可視化的這種方式好比拖拽這種形式就能夠生成。
• ProCode 是最靈活的，你們知道那個代碼是很是靈活的，能夠寫不少邏輯。
• LowCode 是有二者之間混合的。如今汽車有新能源車、有燃油車。新能源車它裏面又分純電動車和混動車，混動的車是一部分燃油，一部分經過電動的，它是結合這兩種的優點，在現階段裏面是這樣看的。

LowCode 本質

這邊是個人一個總結：LowCode 是採用一種產品化或者可視化的方案來開發咱們平常的開發，比方說 UI、一些配置等等，來下降開發成本和門檻，同時來提高一些開發效率。寫代碼須要有一些專業的程序員開發，但低代碼產品，在體驗作的很是棒的狀況下，不須要有很是多的開發經驗，普通的一些業務人員，也能夠經過這個工具去完成它須要的一個產品的開發。

這個左邊是一個可視化。目前來講，代碼它是能夠解決不少一些業務邏輯的問題，咱們在一些特殊的場景或環節，仍是須要經過代碼來進行一些業務的開發，因此咱們會在整個平臺上面嵌入了一個小型的 Web IDE 在線編碼的方式來提高總體的一個靈活性和適應性。

低代碼開發平臺價值

今天講的主題是怎麼去作組件，咱們但願可以經過低代碼方式能多快好省的去作一些組件。什麼叫多快好省？就是咱們的產量高、效率高、質量好和投入人少，是很是理想的一個狀態。並非說咱們不須要去寫代碼，由於咱們發現 LowCode 裏面的代碼量會比較少一點，咱們只但願去少寫一些低效、重複的代碼。

案例

低代碼在不少場景是能夠去應用的，好比中後臺場景，你們在市面上能夠看到不少低代碼的產品，像微軟、阿里的宜搭，若是不知道低代碼的一個具體應用，也能夠去看一下。我今天來說的是導購場景，一個 1688 的無線場景去作這樣的一個低代碼的應用。

3、1688 前臺場景業務背景

你們能夠根據我這個 Case 看看有什麼啓發，在本身的一些應用場景能夠用這種方式去作一些事情。先大體介紹一下 1688 前臺場景業務：咱們能夠簡單理解爲 B 類的淘寶，批發商須要去採購商品能夠在一些工廠或者二級的批發商那裏去採購。總體業務的分配比例是無線的用戶會比較多一點，因此今天講的比較多的是在無線場景這塊的一個應用。大體的一個鏈路是這樣，中間有一些導購的場景，咱們有不少的產品，經過這些導購的場景去給到不一樣端，不一樣端又有不一樣人羣。

從開發頁面到搭建頁面

在作任何技術平臺以前，產品或宣傳須要有一個場景，一般是直接手動去開發一個頁面去知足這樣的一個需求。後面會發現頁面上有不少組件是差很少的，業務的每一個頁面有些是同樣的，有些又是不同，須要有這樣一個組合的關係，因此就會產生搭建平臺。搭建平臺是用來把不一樣的組件來產生一個頁面，這裏有一個比較簡短的演示，上面有不少組件，這些組件是能夠配置參數或數據源就會生成一個頁面。這裏能夠看到兩個組件就能夠把它搭起來，搭起來後，就生成了一個全新的頁面。因此咱們開發的小夥伴就不用每次去開發這樣的頁面了，他就會把精力放在組件上去。搭建平臺是由產品或運營去搭建，這樣能夠把開發小夥伴給釋放出來，解決了一些業務組件的複用問題、增長了一些頁面的靈活性和產出效率。既然平臺可搭建頁面了，那能夠把開發小夥伴的精力重點放到開發組件上去。也就是說經過組件開發，而後在搭建平臺使用，就能夠生成一個頁面，因此咱們的精力主要是去開發組件。

業務場景 - UI 多樣的前臺場景組件

來看一下總體前臺導購場景這樣的一個 Case，你們能夠看到導購場景的組件樣式、排版是很是多的，UI 的展現也是很是多的。

4、面臨問題

這裏就會出現兩個問題：

• 一是 UI 這麼複雜多變。因爲人員是比較有限的，或者說投入的精力是比較有限的，咱們如何在一些固定的、少許的人力投入下，來構建足夠多的一些 UI 組件。
• 二是有不少端的需求。手機端怎麼去面對各類各樣的 APP、怎麼經過一套代碼來完成跨端的需求。

如何在有限的人力下構建多變的 UI 組件

如何快速構建多變的 UI

左邊是典型的導購卡片，咱們怎麼來去作一些提效，最開始想到的是把組件模板提取出來，至關於左邊的樣式、排版把它固定下來。但最後咱們發現組件它在不一樣的 UI 裏有不一樣的展現，你們看下左邊，發現組件模板是很難把它沉澱下來的，UI 是無法進行收斂的。接下來就得想辦法怎麼去構建 UI 進行提效，既然組件模板無法收斂，咱們會在開發層面想辦法怎麼去提效。

UI 主要是由兩部分組成：節點和樣式。形容下面的一些代碼片斷同樣，這個是它的一個節點。咱們但願可以把片斷以前採用手動的方式去把它構建出來，接下來咱們但願經過一些工具，也就是經過半自動的方式，能經過機器的形式把它構建出來。有兩個方式，第一個方式就是說這個節點能夠經過可視化拖拽把它生成出來，第二個方式更加直接的，UED 通常會有視覺稿，咱們是否是能夠直接經過視覺稿來進行導出，這樣的話咱們就能夠跨過 UI 開發這個過程。

快讀構建視圖 - 物料線上化

先來重點講一下可視化 UI 拖拽這種形式。左邊是一個常見的列表，對於這個列表進行拆解，咱們把它每一部分叫作物料，有導航、文字、圖片和容器列表，咱們須要可以把這些物料線上化。這就須要經過一個協議，通俗來講就是經過一個 JSON 描述，把上面的一些物料屬性記錄下來。比方拿這個圖片來舉例，咱們就會分紅兩個屬性：一個是屬性值，比方說圖片地址、渲染方式等；還有一種是樣式，比方說高度、寬度和邊距等等。有了這些屬性了後，可經過這些屬性及物料註冊到線上，經過產品的方式，把剛纔的圖片地址、渲染方式，經過一些可視化 UI 的方式進行展示。能夠看到上面右邊那張圖上，圖片連接、屬性和佈局樣式。

來看一下簡單的一個事例：左邊是正常的一張營銷卡片，這個時候咱們能夠去設置它的寬和高，設置後繼續生效，能夠去改變圖片地址和邊距，這是在編排模式下。在預覽模式下，它能夠正常的展現，這個就是剛纔保存修改過的一個值。

節點拖拽實現原理解析

原理是有一個編排拖拽面板和一個預覽面板，是經過 Schema 協議的方式把它串起來。這是剛纔每一個物料的屬性，下面是它的樣式的描述。有了這個協議後，在拖拽時把這些物料接入進來，經過物料的屬性面板，對每一個物料進行調整，在渲染時把物料導入進來，經過 react create element 直接把它轉成虛擬 DOM 進行渲染。

快速構建視圖 - Sketch 導出

還有一種更簡單的方式就是直接經過視覺稿進行構建。咱們美術同窗或者 UED 同窗，經過 Sketch 設計的一個視覺稿，能夠經過視覺稿的插件把它導出，而後經過一些機器學習的一些算法，能夠把它的 UI 樣式和結構直接還原出來。最後須要通過一些少許的調整，二次加工了後，就能夠把整個 UI 直接能夠展示出來。在這裏咱們再來看一下簡單的一個 Case，這裏咱們已經把它導出來，導出完了後，咱們在面板裏進行導入。你們能夠看到導入的時候它是一個 Schema，這個時候它已經在咱們的系統裏面，咱們能夠對它進行二次編輯。但這裏有個要求，視覺稿須要有必定的規範，須要 UED 同窗按照必定規範去作。這一套工具的叫 imgcook。你們也能夠去搜索它，去用這個工具，它是能夠把一些 PS 格式或 Sketch 格式的一些 UI 直接導入出來，進行代碼的一些識別。

驗證可行性 開發 AB 實驗

剛纔也講了，怎麼去還原這些 UI、怎麼經過工具的形式去作一些 UI，在嘗試着用這個方案的時候，咱們也去跟咱們以前傳統的編碼方式進行了一些比較。咱們作了兩組實驗，來看一下經過這種方式是否可以加快 UI 的開發速度。第二種就是咱們傳統的一些編碼跟樣式的一些開發。咱們發現一旦掌握了可視化的開發之後，咱們在後面的一些組件開發時間上大幅度的降低。這個是咱們作的一些測試後得出的一個結論：它能有效的提高咱們 UI 的構建效率。

將數據和事件與可視化 UI 結合

剛纔咱們看到了在場前臺場景須要展現一個組件，光展現 UI 是不行的。不少時候咱們須要有一些數據，這個是很是必須的，咱們怎麼去展示它裏面的數據是什麼。還有一些事件，UI 點擊了之後，它觸發什麼樣的一個事件，好比說去領個紅包或者發一個請求等等。正常的一個組件它須要有這三個元素進行一些交互和融合，最後才能成爲一個完整的組件。

數據源低代碼設計

咱們再來看一下低代碼，這個平臺裏面它們是如何把三個元素進行結合。剛纔咱們也看了 UI 是怎麼進行產生的，咱們如今來看一下咱們的一個請求，咱們這裏叫一個數據源。這裏是咱們的一個請求，有請求地址、請求入參、請求方法等等，經過一個面板把幾個元素屬性整合起來。填寫請求地址，比方 JSONP、GET 或 POST，下面就是具體的一些參數，在請求時咱們會有一些比較特定的處理，好比回調函數的一些處理。這個時候經過面板的方式是很是去難以去解決的，因此咱們在裏面嵌入了一個小的代碼編輯器，這裏面它是能夠去處理一些回調的一些邏輯等等，咱們能夠把一些東西填在這裏。這個邏輯是怎麼去執行的呢？咱們填完了之後，在線的會把它源碼轉換成 ES5 的語法，在執行的時候，這是個 String，咱們直接 new Function() 就能夠去執行了，這個原理也是比較簡單的。

在線代碼轉化/執行

最後，咱們須要把咱們請求的數據掛載到 UI 上面。咱們須要經過把字段的直接可視化的掛載掛載在 UI 上面，比方說剛纔請求了一個列表，那列表裏面我要展現一張圖片，我要把圖片字段要掛在特定的一個 UI 的一個展現上。仍是以剛纔那個 Case，拿這個數據去作一個展現，這裏是請求的一個數據，你能夠理解成是一個列表，這個列表裏面我會咱們會把這個數據掛在右邊的列表的這樣一個容器上面。有了這個數據，接下來刷出來的結構，就會有一個一個列表的數據。可是這個列表你能夠發現它圖片都是如出一轍的，由於咱們圖片如今默認是一張靜態圖，咱們接下來須要把這張靜態圖替換成一個動態的圖片，這裏咱們會有一個綁定變量。在綁定變量裏面，由於是一個循環體，這裏每個循環的 key，咱們把它設置爲一個 item，這裏取的是 item 的一個字段，這個 item 就是數據的一個字段，這就叫 image 字段，咱們把它綁定上了之後，這個時候咱們從新刷一下，咱們會發現案例表的數據已經發生了變化，已是變成咱們數據的真實的一個值。

數據掛載 UI

可視化開發還有一個好處，咱們常常會去作二次開發，好比一個組件開發完了之後，過了一段時間，另一個同窗去接手作這個事。這個時候可能他要去迭代一個需求，需求也很簡單，好比改一個字段或增長一些小的邏輯等等。正常的狀況下，咱們須要把以前的代碼通讀一遍，知道它具體改的地方在哪裏，具體它的邏輯在哪，可是咱們經過可視化左邊的展現，會很是直觀，比方說我要改一個文字，我就選擇文字，把文字綁定的一個變量作一個改動，或者說我作一個邏輯變更。這個在可視化的一個產品裏面，咱們是能夠很是方便的去作一些二次迭代的，這也是整個低代碼平臺對後面維護的一個好處。

如何面對跨端的需求

第二點咱們再來說一下如何去作一些跨端的需求。

多端能力支持

咱們如今有不少端，比方說 Web 端、在阿里內部的一些 APP 裏還會有一些 Weex 端，其餘的一些端上，比方說它要支持一些小程序等等，阿里內部有一個 Rax 框架，這個框架它是能夠把它轉成 Weex 端、Web 端。Rax 框架它也能夠經過轉碼這種形式去支持小程序。咱們怎麼去把咱們把低代碼 Scheme 實現相似 Rax 轉碼，咱們也是經過 AST 的這種轉碼的方式。由於 Schema 是一個跟代碼無關、跟 DSL 無關的這樣一個邏輯性的描述。比方說你能夠把 Schema 轉成 React 形式、Rax 形式、甚至 Vue 的形式均可以。可是我最初的 Schema 是不會有任何變化。比方說你後面再過一段時間，可能有另一種 DSL 產生的，或者說另一種更高級的 DSL 產生，我照樣也是能夠將 Schema 經過必定的轉換邏輯把它轉出來的。因此經過 Schema 的好處就是說它能夠很是簡單的去收攏各類 DSL 的這樣一個能力。

Schema 轉碼方案

具體怎麼去經過 Schema 去轉，咱們會把 Schema 裏面會進行一些拆解，Schema 裏面有不少的節點，比方說有一些專門負責作視圖描述的節點，它告訴你這個結構是怎麼樣的。還有一些數據請求節點，告訴你這個請求地址、請求參數和請求類型等。還會有一些生命週期的參數，還會有一些交互事件的一些函數，咱們把它進行一些拆解，拆解了之後，經過 AST Babel 插件進行一個解構，把它轉成形如這樣的一個目標的 DSL 的代碼。

CBU 無線場景 LowCode 落地數據

這個是咱們本身的一個落地數據，咱們用了這個產品之後，咱們發現內部的提效也是很是明顯的，提效了 400%。不少時候咱們須要去寫，可是咱們用了這種開發方式後會發現可能須要一個簡單的拖拽就能夠了。

收斂技術，高效協同

最後來說一個問題，就是技術收斂跟高效協同的問題。

在一個團隊開發的過程當中，常常會出現一些問題，比方說我須要用哪一個組件、我不知道哪一個組件能用、個人組件構建發佈它是怎麼去處理的、不少文檔比較散不大好找和剛纔說的二次開發的問題（去看別人代碼，程序員最怕看別人代碼很是累）。這就是咱們原先線下的開發方式，由於它是每一個人本身去執行的，很難收口，規範也很難執行。固然咱們也能夠經過一些特定的規範，比方說工程的這種方式來作一些收斂，這也是一種方式。咱們能夠把這種方式搬到線上，工程也好其餘方式也好，把它線上化，你們入口是同樣的，你們進去都是一個入口。我能夠在這個平臺裏面我能夠知足我作任何的事情，線上的話我能夠很是好的去管控你，很是好的去規範，比方發佈構建和代碼的質量，能夠把它所有收攏起來，只要看一個文檔就行，不須要去管其餘的東西。這種比較適合一些對技術要求不是特別高的，可是它又要知足它的一些業務的整個場景的推動。由於是一個線上的，因此它是能夠經過 Web 平臺作一個統一的收攏，對使用者來講，只要體驗好這個產品，就能夠完成一些開發任務。

整合開發鏈路

這個是傳統的開發鏈路，它有不少構建、搭建環境等等。可是咱們經過線上化後，都是採用雲構建、雲預發和部署的方式，它沒有這種環境這種概念，由於它都是在 Web 上面，因此只須要作一些開發調試、接口調試等基礎工做就行，其餘的工做都是經過平臺或者產品的方式把它包裝好就好了。由於步驟開發少了、鏈路少了，開發效率確定也會提高。

構建與發佈

咱們還常常會有一些發佈構建的問題。比方說咱們須要建倉庫，不一樣的部門、不一樣的公司建倉的腳手化等等都是不太同樣。新人都須要把流程所有走一遍，可能還會有一些其餘雜七雜八的細節，好比說安裝依賴、調試方式等等。咱們經過產品的方式、低代碼的方式，怎麼去作呢？新建倉庫或叫初始化，經過在 Web 上去新建一個組件，在組件裏面把一些邏輯寫在後臺，或者調試的時候，經過實時的預覽，只要按調試按紐，就能夠把預覽界面展現出來，不須要去寫什麼其餘的一些命令，或者是裝其餘庫等等。

這個是咱們新人註冊的時候，只要填一些信息就行。調試的時候咱們會把這些包所有都會拉下來，這個是調試的這樣一個邏輯。咱們還會有一些本地開發和構建的問題，若是有線上線下的構建，咱們須要去作一些分支，或者說作一些發佈部署等等。經過雲構建的方式，能夠把這寫東西所有放在後臺，前臺只要發一個命令或請求，能夠在雲服務器上把這些東西作了。

傳統開發與低代碼開發對比

還有一些傳統的開發方式，比方文檔、組件庫，代碼的開發風格你們都是因人而異的，每一個人的開發方式寫法都不同。經過平臺的方式，有統一文檔，物料也是在線的，你們在面板裏面有多少物料，你們能夠本身選，反正有就有了，沒有的話咱們就提需求，你們再去擴充，這樣是一個很是統一的。最後轉出來的代碼都是同樣的，由於你們都是用機器轉的，風格是徹底統一的。對整個團隊或者說對一個技術團隊有一個很是好的收斂。

低代碼開發平臺的目前存在的問題

低代碼也有本身問題，並非說特別牛逼的。

• 但相比傳統的開發體驗而言，它須要有必定的學習成本，對於一些特別是一些開發習慣來上來說，由於有些開發同窗他習慣了手寫代碼，忽然有一天對他說不用手寫代碼，只須要拖拽用產品這種可視化方式，他可能不太習慣，這有一個成本習慣去調整的，這是一個問題。
• 有些產品特別是一些中後臺的產品，它的邏輯很是複雜，可能有幾千行，他有各類交互，這個時候你把這個東西放到可視化的產品來講，它自己對低代碼平臺產品的體驗來講是很是高的，須要有一個更好的這樣的體驗，才能把這些邏輯經過 UI、經過產品、經過可視化去把它搭建起來，否則維護起來會很是麻煩，可能比你單獨寫代碼還麻煩一點。
• 是否是能夠跟現有的一些源碼模式可以有一個更好的互通。比方說組件的形式，能不能把一些已經寫好的組件導入進來，我作完的組件也可以跟其餘的一些源碼組件不一致，我都是同樣的，你們都是能夠在一個大的一個容器裏面去用，可以跟現有的源碼體系作一個更好的結合。

5、將來規劃

這是咱們將來的一些規劃，咱們這個引擎目前用的是阿里本身寫的一個低代碼引擎，咱們也努力的去把它完善，後續還會把它作得更加好用，如今只是一個能用的方式。咱們但願後面可以輸出一些通用的引擎，可能咱們在之後會把引擎進行開源，你們能夠把全部的業務，只要你用 React 或者 Vue 的產品，這種框架我均可以用引擎去解決一些業務上的一些問題，甚至我能夠在一個引擎上面進行二次開發，造成本身在業務、公司或部門上的比較業務化的這樣一個平臺，這個引擎就像一個框架同樣，去解決一些問題。

6、總結

總結一下，主要講了兩大問題。第一個是說咱們怎麼經過低代碼有限的方式來構建的一些 UI 組件，這裏咱們講到了是經過一些智能導出，經過可視化拖拽的形式來替代手寫快速實現 UI 開發。咱們怎麼來進行一個跨端需求，比方說多 DSL 的需求，咱們能夠把 Schema 做爲一箇中間態，這個 Schema 跟 DSL 無關，經過一些轉換的方式，這裏寫的是用 AST 方式去轉成不一樣的端。最後咱們也講到了一個咱們怎麼樣經過雲平臺方式去作一些技術收斂，經過在線的開發方式來解決咱們以前線下開發方式的一些問題。

7、團隊介紹

介紹一下咱們的團隊，就是咱們這邊的一個 CBU，我是屬於 CBU 搜索廣告團隊的，我這裏打個廣告，咱們整個團隊的話是負責作 CBU 搜索，Web 無線的，還有 CBU 大流量廣告這兩塊業務。咱們的核心的技術也用了不少大流量的 Node BFF 的應用，包括咱們剛纔講到的低代碼的一些開發方式，在咱們業務裏面已經全面啓用了，咱們也有不少一些前端加智能算法，智能算法在咱們的業務裏面去用。有興趣的同窗、想投簡歷、想跟我聊一些低代碼相關的一些同窗也能夠加我一下個人微信，後續咱們進一步進行溝通。

8、推薦書籍

我推薦的書是一些老書，你們可能都聽過，可是不必定你們都看過，但我以爲這些書是一些比較基礎的比較經典的書，你們能夠有時間的話能夠去看一下。

9、QA

Schema 裏面包含了 onClick 函數的字符串，那怎麼處理做用域呢？或者跳轉頁面這些操做應該要怎麼處理？

在 Schema 會有函數，首先實例化。低代碼是以組件或者頁面維度，因此在實例化這個函數的時候，咱們會把容器的一些對象、函數的 this 對象和函數的 target 對象等等，咱們會把它們注入進來，咱們會把一些父元素的一些節點、一些變量咱們會把它注入進來。這樣在函數裏面使用 this 或其餘屬性的時候，是能夠去用到這些對象。

若是是正常的頁面跳轉的話，是能夠在咱們物料上面去配一個連接地址，去作一些頁面的跳轉，咱們整個低代碼也是能夠以頁面緯度作去作頁面的。你能夠在整個系統裏面去配置一個路由，去處理一些頁面跳轉關係。

---

別忘了 6-5 下午直播哦，點我上車👉 (報名地址)：

全部往期都有全程錄播，上手年票一次性解鎖所有

---

期待更多文章，點個贊