【🧪 前端實驗室】2020 前端可視化搭建小報告 - 02 - 鏈路、架構和難點

該篇做爲前端可視化報告的第二篇，主要簡述前端可視化搭建的鏈路、架構和難點，內容含有大量圖文，部分小節的內容只有配圖，後續有機會繼續完善。html

0. 可視化搭建的使用鏈路

在開篇以前，咱們先把視角提升一點，關注到使用的鏈路上，對於一個用戶（研發 or 非研發），如何使用咱們構建出的可視化搭建平臺？前端

Low-code: 若是面向的是研發，場景是中後臺或者 toB 的一些業務，咱們須要搭建的就是低代碼生產鏈路，用戶只須要改動少許的代碼就能完成一個應用或者頁面的全鏈路流程。vue
No-code: 若是面向的是非研發（如產品經理、設計師），場景大多數都是一些簡單的營銷頁面，使用者會但願徹底不涉及任何代碼，就能把一個頁面或者多個頁面發佈到線上，同時還能保證可維護、可迭代、可回退、可監控。git

瞭解了使用者的鏈路以後，咱們再理解可視化搭建的一些設計思想會順暢不少。github

1. 可視化搭建架構

廢話很少說，放上收集到的一些架構圖：web

政採雲 - 魯班架構圖vue-router
京東 - MPMnpm
京東 - Atom後端

下圖是 Atom 可視化搭建系統的服務端架構設計模式
阿里淘系技術部 - iceluna
- iceluna架構圖 - 總體架構
- iceluna架構圖 - 流程能力圖
阿里淘系技術部 - imgcook
阿里媽媽 - 淘積木
阿里 - 雲鳳蝶

從這些優秀的項目架構中，筆者也試着概括了一下，架構圖以下：

2. 可視化編輯器（核心） Low-code Visual Editor

iceluna的編輯器架構以下圖所示，一個框架涵蓋了三大模塊（編排、渲染、內核）：

可視化搭建的核心是編輯器，而編輯器的核心是組件。

雲鳳蝶將編輯器對組件的操做劃分紅了五個具體的步驟，以下圖所示：

2.1 組件的識別和導入

由開發專家，基於咱們提供的開發規範，製做出精良且模塊化的組件，上傳至咱們的組件倉庫。

基礎的組件元素，能夠經過專業的組件庫（如 AntDesign）提供，這樣在設計規範和實現規範上都有了較低粒度的一個保障。

那麼組件的識別和導入大體上完成了什麼呢？這裏列舉了兩點：

獲取組件屬性描述
生成組件 bundle

2.2 組件的拖拽和組合

組件拖拽和組合的過程，其實有點像拼圖（二維）和搭樂高（三維），這也多是爲何不少可視化搭建起名叫作 「積木」、**「樂高」**吧。

拖拽的實現如今已經挺成熟的了，不管 Mouse 事件的監聽或者 HTML5 提供的 drag 和 drop 方案，都能很好地完成拖拽這個行爲。

組合的過程咱們這裏看一下松果出行的 lego 項目是如何作的：組件在提供之初就設定了它的接口和配置，並符合定義的 JSON Schema，配合 Vue 的動態組件特性來實現動態的頁面渲染，用戶也能夠經過編輯器中的選項來控制組件的呈現形式及組合形式，最後完成組件間的拼裝。

2.3 組件的配置和擴展

常見的組件都會提供基礎的屬性配置，好比位置、大小、顏色、佈局、文本、背景等。

但有一些組件，咱們想給它加一點通用高級屬性，如：是否渲染、是否隱藏、重複、通用樣式，懸浮提示，固釘，徽標，loading 加載中等，每個通用高級屬性都是 Web 應用研發中某一類常見功能的抽象與封裝。這種實現的過程，和設計模式中的裝飾器模式一致 🎄。

具體如何作呢？舉個例子 🌰，在 React 的技術棧中，咱們能夠用 HOC（Higher-Order Components 高階組件）去包裹原始組件實現這些加強功能。

高階組件（HOC）是 React 中用於重用組件邏輯的高級技術。具體而言，高階組件是接受組件並返回新組件的函數。

基本屬性配置（如大小、顏色、背景、文本等）
橫向能力擴充（如 click 事件、懸浮提示、連接跳轉等）

2.4 組件編排和自適應

這裏會涉及多個問題，如

編輯時拖拽組件的二維座標如何造成嵌套組件樹
當屏幕尺寸變化的時候，組件自身，組件與其餘組件之間的位置關係如何變化

組件樹的生成是爲了解決對組件包含關係的描述，最多見的好比父子關係、兄弟關係等，咱們能夠經過盒模型的包含識別，來生成一顆相似 DOM 樹的組件樹。

自適應的問題，如今前端領域已經有很多解決方案了，如 rem、彈性佈局、grid 佈局等。

DSL 流派（半邊代碼半邊實時呈現） vs Flex 流式編排 vs 類 PS、Sketch 自由編輯模式
無限畫布 && 柵格系統 && 參考線

2.5 組件的狀態和聯動

這一塊的事情其實很是多，包含了狀態定義、狀態存儲、狀態共享、數據接入、組件聯動等，具體的我放到了第三小節裏展開介紹。

打統統信渠道（如 http 通訊、window 的 postMessage 等）
狀態外置（如 Redux、Vuex、Rxjs，也能夠自研一個相似 Vue 響應式內核架構的發佈訂閱模型）

3. 物料管理和組件流通

從物料的寬泛概念理解，諸如圖標、字體、圖片、多媒體、3D 模型等設計資產，以及組件、圖表、微件、區塊模板等開發資產，都屬於可視化搭建系統中的物料。

這麼多類型的物料，如何管理和流通就是一個比較讓人頭疼的問題。

咱們既要容許新的物料進入，也要容許開發者能快速便捷地修改和發佈物料，還得保證這些物料是可以被組合和嵌套的。

下圖展現了雲鳳蝶是如何快速導入 npm 組件的：

下圖是阿里 iceluna 關於物料和組件流通的架構圖。

4. 數據接入、模塊通訊及狀態共享

數據如何在組件內流通是一個作可視化搭建避不開的問題，這個小節將針對數據接入和模塊通訊詳細地探討一下解決的方案。

4.1 數據接入

咱們先講數據接入，一個組件接入的數據類型可能會多種多樣，大體上能夠分爲兩類: 接入式數據接口和嵌入式數據服務。前者須要咱們接入數據，後者須要咱們提供一個標準容器。咱們能夠經過 API 調用、在線服務調用等手段，完成組件的數據接入。

Database / API 接入數據接口
Service / Map / Email 嵌入數據服務（好比郵件、地圖）

4.2 模塊通訊和狀態共享

在基於 Vue 技術棧的開發中，組件間的通訊存在多種實現手段，好比

$parent/$children/$ref 直接獲取組件實例上的屬性和狀態，僅限父子組件
經過Prop傳遞數據單向的數據流通，僅限父子組件
$emit && $on 事件機制，通常咱們會在外部實現一個EventBus做爲事件總線
VueX外置全局狀態管理和共享

在可視化搭建中，實際上是同樣的道理，咱們能夠

對組件進行生成惟一的實例 id，經過這個 id 來訪問組件的數據
對組件的接口進行聲明，告訴用戶它能接收什麼樣的數據、傳遞出什麼樣的數據，而後當用戶完成組件的組合，咱們能夠自動爲對應的父子組件接上數據。
對組件包裹一層事件機制，實現對外發送組件狀態和接受組件數據的能力，同時事件會在外部的事件總線上流動。
外置狀態管理機制，實現原理相似 MVVM 框架的狀態管理器（Vuex、Redux）

這裏舉一個業界的例子，雲鳳蝶爲每一個頁面都提供一個相似 MMVM 架構下的 Controller 角色的 View Model 文件，從而實現視圖的狀態驅動，其內容就是導出一個普通的 TypeScript Class，包含了狀態屬性和狀態方法。

在頁面 Controller 中定義好變量和方法以後，用戶能夠經過屬性面板的交互操做：

將組件的 props 綁定到 Controller 內的變量
將組件的 event 綁定到 Controller 內的方法

實現了數據的流通後，雲鳳蝶還爲此作了針對更新視圖響應式的優化，核心架構就是 Reactive （響應式）和 Observable （可觀測），實現的原理就是 Vue3 也使用了的 ES6 Proxy 封裝。優化以後，當數據發生變化，就不用全局刷新，只須要刷新依賴這個數據的組件便可。

5. 畫布（佈局方案、柵格及參考線、邊界控制）

畫布是咱們處理組件，完成組件組合等操做的一個載體。

5.1 畫布的佈局

畫布的佈局大體上能夠分爲兩類：

佈局類型	示意圖
抽屜式（瀑布流式）
自由式

抽屜式自上而下順序排列，能夠更換組件位置，但不能實現元素定位，沒有層級概念，遇到複雜佈局或者須要疊放元素時不夠靈活，若是須要實現複雜頁面的效果則須要引入複合 UI 組件的概念，它須要大量現成的 UI 組件。優勢是將可操做程度限定在了一個可控的範圍內，對非設計人員來講只須要經過現有 UI 組件進行拼裝便可生成一個美觀度較高的頁面。

自由式徹底可隨意拖拽元素位置，自由度高，只需幾個基礎 UI 組件便可，存在層級概念，可任意疊放拼裝，在無成品 UI 組件的狀況下 diy 出複雜頁面。但頁面不可控，對操做人員的美感要求更高。更適合 UI 同窗操做使用。下圖只是一個複雜佈局的例子，關注佈局便可先不要管業務邏輯如何實現。

5.2 & 5.3 畫布的柵格、參考線、邊界控制（待完成）

6. 多端和多框架適配

iceluna - 多框架適配
MPM - 多端適配

7. 數據模型 Model / 數據約束 Schema

數據模型和數據約束是可視化搭建很是核心的一部分，良好的模型和約束設計能幫助咱們更好地實現可視化搭建。

8. 海量部署

這裏展現一套阿里的淘積木產品，所設計並落地的海量部署方案。

核心問題
初步方案
小規模架構
模型創建和方案設計
最終架構

咱們在實現海量部署中，可能會遇到的一些關鍵性問題：

Node 緩存回收機制閾值管理
IPC 大文件傳輸
冷部署和熱部署、容災管理

9. 微前端的應用

微前端：將前端總體分解爲小而簡單的塊的模式。這些塊能夠獨立持續開發、持續測試和持續部署，同時仍然聚合爲一個產品出如今客戶面前。

下圖是常見的微前端架構示意圖：

微前端的思路其實特別契合可視化搭建的須要，由於對於組件而言，咱們儘量地不對上傳組件者如何實現組件進行限制，由於有些人會習慣用 React、Vue 或者 Angular，有些人會寫一些原生 js 的組件，這就要求咱們在封裝組件完成搭建的時候，提供一個可兼容各類組件的容器，這和微前端的思路不謀而合。

社區知名度較高的微前端解決方案是single-spa，飛冰在進行調研以後，結合自身的可視化搭建業務，提出了一種成熟的微前端方案icestark，應用在阿里創做者平臺等項目上，大體的實現思路以下：

引入框架應用（容器，Container）和子應用（項目，Item）的概念
- 框架應用負責系統總體佈局以及子應用的註冊、加載與渲染。
- 子應用是一個傳統的 SPA 應用（可包含一個或多個頁面），會打包出 bundle 同時發佈到 CDN，那麼咱們須要在框架應用中註冊管理全部子應用，而後在適當的時機加載對應的子應用 bundle 並將其渲染到指定節點（系統佈局裏面）
捕捉子路由的變化

和vue-router定義子路由很類似，並且也是經過劫持 history 的 API 實現路由捕獲
怎麼渲染子應用到指定節點

現代前端框架都提供了掛載的函數
- React ReactDOM.render(<App />, document.getElementById('#root'))
- Vue Vue.createApp(Counter).mount('#counter')
若是不是用框架實現的，也能夠用原生 js 封裝一個mountJsChildApp函數實現掛載

10. Serverless

Serverless 也是很是前沿的一個技術，但其實使用起來不會那麼複雜，只要瞭解它的做用，就能明白如何結合 serverless 的能力。

飛冰：基於 ServerLess 的能力，在前端項目中能夠完成 api 的編寫以及頁面的渲染，不須要再建立一個後端應用。

那麼 ServerLess 提供的究竟是什麼能力呢？這裏引入騰訊雲目前的爆款 Serverless 產品-雲函數 SCF 的一段說明:

雲函數 SCF 是騰訊云爲企業和廣大開發者們提供的無服務器執行環境，您無需購買和管理服務器，而只需使用平臺支持的語言編寫核心代碼並設置代碼運行的條件，代碼便可在騰訊雲基礎設施上彈性、安全地運行。騰訊雲徹底管理底層計算資源，包括服務器 CPU、內存、網絡和其餘配置/資源維護、代碼部署、彈性伸縮、負載均衡等。代碼按需運行，空閒時不收費。使用雲函數將幫您免除全部運維性操做，使您更加專一於核心業務的開發，實現快速上線和迭代，把握業務發展的黃金時期。

喔哦，原來是不用管服務器搭建了，並且還能負載均衡、按需運行，這還能夠幫咱們節省搭建的成本！

那麼，怎麼用呢？親，SSR 能夠了解一下！咱們只要在雲函數 SCF 裏實現對頁面的 Render 就行啦！具體如何實現你們應該能夠經過搜索引擎找到對應的實現文章。

此處可能須要雲服務商提供臨時域名用於訪問站點

11. AI的引入和結合

目前 AI 從機器學習不斷髮展到了如今大熱的深度學習（神經網絡），將來 AI 到底可以發展得有多快誰也不知道，說不定咱們就能在有生之年看到「奇點」的來臨。

主要利用 AI 的識別和推導能力（識別也是一種推導）來協助可視化搭建，業內比較典型和成熟的成果如 imgcook，下面是幾張關於該產品的說明圖:

核心想法
產品的大體架構
用戶的操做界面

12. 其餘的一些思考

實現前端可視化搭建是一個耗時長久的浩大工程，期間可能還會遇到如下技術難點，因爲篇幅有限暫時不一一深刻研究，後續有機會能夠持續補充和完善：

無限畫布（容許用戶在很是廣闊的虛擬畫布上進行自由的創做，讓設計師可以直接在平臺上像在sketch上同樣工做）
容災系統（解決服務器宕機或者其餘災難發生時，保障用戶數據的問題）
代碼可用率（檢驗是 low-code 仍是 no-code 的最佳標準）
多人協同（方便團隊協做快速完成一個大型的複雜應用）

# 參考文章

這裏不少資料，來源於本人蔘與的早早聊大會的講師 PPT 材料，在這其中我也作了一些篩選和整合，加入了本身製做的圖表，也歡迎各位關注這個乾貨滿滿的會議。

再列舉一些其餘參考的文章或者網站：