新聞中心
- H5-Dooring 開源版本
- 可視化低代碼技術(shù)集合
- H5-Dooring在線體驗
Dooring無代碼產(chǎn)品技術(shù)演進
兩年前我設(shè)計了H5-Dooring的第一個開源版本, 之后陸陸續(xù)續(xù)迭代了兩年, github star已達到6.5k+, 也找到了很多志同道合的小伙伴, 一起研發(fā)Dooring系的搭建產(chǎn)品, 如:

- h5-dooring | 可視化搭建解決方案
- mitu-editor | 開源圖片編輯器
- v6.dooring | 可視化大屏搭建平臺
- dooringx | 可視化搭建框架
從技術(shù)設(shè)計和產(chǎn)品規(guī)劃上, 這幾年也總結(jié)摸索出了一些經(jīng)驗和實踐, 接下來我就和大家一起分享一下H5-Dooring 的技術(shù)架構(gòu)設(shè)計與演進。
底層搭建協(xié)議標準化
我們都知道任何低代碼或者零代碼搭建產(chǎn)品都非常注重底層搭建協(xié)議, 這些產(chǎn)品通常會設(shè)計一套向上兼容且可擴展的DSL結(jié)構(gòu), 來實現(xiàn)頁面元件的標準化配置, 并支持元件的向上擴展。
上面這張圖是我在設(shè)計 V6.Dooring 可視化大屏搭建平臺的編輯器架構(gòu)圖, 這里的底層搭建協(xié)議可以認為是 搭建基礎(chǔ), 也就是我們常說的 “經(jīng)濟基礎(chǔ)決定上層建筑”。
在設(shè)計H5-Dooring 搭建平臺前, 我也參考了很多標準化軟件數(shù)據(jù)協(xié)議, 給我啟發(fā)最大的就是 ODATA, 它是微軟于2007年發(fā)起的開放協(xié)議, 主要由以下幾部分組成:
「核心協(xié)議」: 主要定義了開放數(shù)據(jù)協(xié)議的核心語義和行為。
- 「URL規(guī)范」: 主要定義了一系列推薦(非強制)采用的構(gòu)建用于訪問OData服務(wù)中的數(shù)據(jù)和模型的URL的規(guī)則。
- 「通用格式定義語言(CSDL)」: 它定義了OData服務(wù)的「EDM」模型的一種XML格式的表現(xiàn)形式。
- 「擴展的巴科斯范式(ABNF)」: 定義了構(gòu)建OData請求和響應(yīng)URL的「巴科斯范式」。
為了讓可視化搭建平臺的組件數(shù)據(jù)標準化且可擴展, 這里我分享一下H5-Dooring的Schema設(shè)計。
Schema 分兩部分:
- editData 組件可編輯屬性的數(shù)組
- config 組件真正消費的數(shù)據(jù)
editData 詳解
editData 是 組件屬性可編輯項的數(shù)組, 每一項里面包含了如下字段:
- key 屬性名
- name: 屬性名的中文顯示
- type: 屬性的可編輯類型
- isCrop(可選)
- cropRate(可選)
- range(type 為'Radio'或'Select'時的選項數(shù)組)
- 后期可能會擴展(詳細結(jié)構(gòu)可參考Dooring 開源版本)
key和name 都可以按照組件屬性的語義來定, 這里值得一提的是 type. 不同屬性的值類型不同, 所以我們編輯項的 type 也不同, 所有的類型如下:
- Upload 上傳組件
- Text 文本框
- RichText 富文本
- TextArea 多行文本
- Number 數(shù)字輸入框
- DataList 列表編輯器
- FileList 文件列表編輯器
- InteractionData 交互設(shè)置
- Color 顏色面板
- MutiText 多文本
- Select 選擇下拉框
- Radio 單選框
- Switch 開關(guān)切換
- CardPicker 卡片面板
- Table 表格編輯器
- Pos 坐標編輯器
- FormItems 表單設(shè)計器
config 詳解
config 本質(zhì)上是一個對象, 也就是組件所能暴露出來的屬性集合, 和 editData 數(shù)組每一項的key 一致, 如下:
{
cpName: 'Header',
logoText: '',
fontSize: 20,
color: 'rgba(47,84,235,1)',
height: 60,
fixTop: false,
menuList: [
{
id: '1',
title: '首頁',
link: '/'
},
{
id: '2',
title: '產(chǎn)品介紹',
link: '/'
},
]
}我們通過以上的設(shè)計規(guī)范, 就可以輕松制作一個可實時編輯的低代碼組件:
可以在Dooring官方文檔體驗: 低代碼組件案例。
搭建模式多元化
最開始設(shè)計H5-Dooring的時候為了最大限度的降低用戶的搭建成本, 我采用了智能網(wǎng)格布局的方式來搭建頁面, 用戶只需要在二維空間像搭積木一樣選擇適合的組件就可以快速的制作頁面:
這樣雖然可以降低用戶的搭建難度, 并能滿足一部分受眾的搭建需求, 比如說簡單的官網(wǎng), 活動頁面制作,下面是一個搭建的比較有代表性的例子:
但是對于平臺方, 為了滿足更多場景的頁面深度制作, 就必須提供不同場景不同行業(yè)的組件物料, 這將對研發(fā)帶來巨大的壓力(雖然也一直在添加新組件)。
另一方面, 目前上很多H5活動制作平臺基本上都采用的自由布局的模式搭建, 好處就是可以最大限度的還原設(shè)計稿, 滿足更靈活的搭建需求, 缺點就是使用成本比網(wǎng)格布局的模式要高, 還會涉及圖層的概念。
當然綜合評估下來, 確實很有必要給一部分用戶提供自由布局的模式, 所以在技術(shù)層我設(shè)計同時兼容網(wǎng)格布局和自由布局的搭建方案. 當用戶在搭建時, 可以輕松選擇自己適合的搭建模式:
同時為了滿足自由布局下組件的層級管理, 我又設(shè)計了圖層管理面板和圖層操作, 來快速的管理頁面元素, 當然圖層管理面板 對網(wǎng)格布局 也同樣有一定積極作用, 比如快捷的操作組件。
可擴展的插件系統(tǒng)
在前面提到了可視化搭建平臺的統(tǒng)一搭建協(xié)議和搭建模式, 在這兩個核心要素完成之后, 我們就很容易的去設(shè)計我們的插件系統(tǒng)。
從插件系統(tǒng)的本質(zhì)來看, 核心價值是對頁面操作的整個周期里為頁面賦能, 而頁面的本質(zhì)是數(shù)據(jù)(也就是DSL集)。
所以只要有標準的數(shù)據(jù)規(guī)范, 我們自定義的插件就可以很輕松的來對頁面進行賦能, 類似于各種技術(shù)里面的中間件. 下面是一個例子:
{
"pageConfig": {
"allowOverlap": "freedom",
"isLogin": false,
"bgColor": "rgba(16,20,29,1)",
"bgSize": "100%",
"title": "H5-Dooring官網(wǎng)"
},
"tpl": [
{
"id": "276059",
"item": {
"category": "base",
"config": {
"cpName": "XButton",
"id": "",
"bgColor": "rgba(22,40,212,1)",
"width": 190,
"marginTop": 0,
"round": 16,
"text": "按鈕",
"fontSize": 15,
"color": "rgba(255,255,255,1)",
"animation": "none",
"animationTurn": 1,
"delay": 0,
"interaction": {
"type": "link",
"title": "",
"params": "",
"content": "",
"height": 300,
"width": 300,
"okText": "",
"cancelText": "",
"onOk": "",
"btnColor": "rgba(20,54,226,100)"
}
},
"h": 23,
"type": "XButton"
},
"point": {
"w": 24,
"h": 23,
"x": 0,
"y": 0,
"i": "276059",
"moved": false,
"static": false,
"isBounded": true
},
"status": "inToCanvas"
},
{
"id": "260487",
"item": {
"category": "base",
"config": {
"cpName": "LongText",
"id": "",
"text": "我是長文本有一段故事,dooring可視化編輯器無限可能,趕快來體驗吧,騷年們,奧利給~",
"color": "rgba(60,60,60,1)",
"fontSize": 14,
"indent": 0,
"lineHeight": 1.8,
"textAlign": "left",
"bgColor": "rgba(255,255,255,0)",
"padding": 0,
"radius": 0
},
"h": 36,
"type": "LongText"
},
"point": {
"w": 24,
"h": 36,
"x": 0,
"y": 23,
"i": "260487",
"moved": false,
"static": false,
"isBounded": true
},
"status": "inToCanvas"
}
]
}上面是H5-Dooring生成的一個頁面DSL結(jié)構(gòu), 如果我們要對頁面元素進行統(tǒng)計分析, 或者實現(xiàn)出碼, 國際化, PSD解析轉(zhuǎn)化等功能, 只需要對數(shù)據(jù)結(jié)構(gòu)進行分析和處理即可。
所以說在H5-Dooring平臺實現(xiàn)自定義的插件還是非常容易的, 也是低代碼或者無代碼需要重點規(guī)劃的一個環(huán)節(jié)。
可擴展的組件編輯器
H5-Dooring平臺的組件編輯器主要是對組件屬性進行編輯,比如:
- 基本樣式
- 交互設(shè)置
- 動畫設(shè)置
當然還有全局的數(shù)據(jù)源配置. 如下:
同時由于我們的組件數(shù)據(jù)協(xié)議高度統(tǒng)一, 所以如果想擴展屬性配置, 也非常容易, 我們只需要按照數(shù)據(jù)協(xié)議添加屬性即可:
同理, 「v6.dooring」 也采用相似的架構(gòu), 所以我們可以輕松擴展組件的屬性:
有關(guān)可視化大屏搭建平臺的技術(shù)實踐可以參考我的另一篇文章 從零設(shè)計可視化大屏搭建引擎。
多端搭建支持
由于Dooring的技術(shù)棧采用React, 并實現(xiàn)了標準的數(shù)據(jù)協(xié)議層, 所以我們可以利用類似 Taro 等跨平臺框架實現(xiàn)多端搭建, 對于我們常用的媒介如移動端, Pad和PC端, 目前編輯器也提供了快捷的切換模式:
所以我們可以輕松的實現(xiàn)不同端的搭建, 實現(xiàn)原理本質(zhì)上是通過切換畫布大小, 并同比例更新元素的計量衡。
圖層管理, 讓設(shè)計更高效
圖層管理模塊也是在Dooring支持了自由布局之后才上線的功能. 因為我們頁面中組件的數(shù)據(jù)結(jié)構(gòu)中包含統(tǒng)一的物理信息:
- 層級
- 可見性
- 類別
- 大小顏色等外觀
- 事件 / 交互 / 動畫
所以我們只需要分析頁面的組件集合, 就可以輕松的渲染出頁面中的元素圖層信息:
有了圖層的概念我們其實可以做很多有用的事情, 比如:
- 多選組件
- 編輯組件
- 刪除組件
- 鎖定組件
后面 Dooring 也會基于圖層能力迭代更多提高用戶搭建銷效率的功能。
低代碼組件 & 模版生態(tài)
在Dooring 的迭代中花了大部分精力在優(yōu)化用戶搭建體驗和協(xié)議標準化上, 對于組件物料的豐富上, 我也做了一些設(shè)計, 最近也發(fā)布了一套低代碼組件庫的原型:
我們可以輕松的像寫 React 組件一樣來實現(xiàn)低代碼組件, 并支持線上實時編輯, 一個基本的例子如下:
import styles from './index.less';
import React, { memo, useState } from 'react';
import { MenuOutlined } from '@ant-design/icons';
import { IHeaderConfig } from './schema';
const Header = memo((props: IHeaderConfig) => {
const {
cpName,
bgColor,
logo,
logoText,
fontSize,
color,
showMenuBtn,
menuColor,
height,
} = props;
const [showMenu, setShowMenu] = useState(false);
const toggleMenu = () => {
setShowMenu(!showMenu);
};
return (
className={styles.header}
style={{ backgroundColor: bgColor, height: height + 'px' }}
>
{logoText}
{showMenuBtn && (
<>
className={styles.menuIconWrap}
onClick={toggleMenu}
style={{ color: menuColor, borderColor: menuColor }}
>
>
)}
);
});
export default Header;
通過這種標準化的方式, 我們可以給 Dooring 平臺提供更為豐富的組件物料。
除了基礎(chǔ)物料組件之外, 為了從更大粒度提高用戶搭建的效率, 我提供了模版功能, 我們可以把重復(fù)的區(qū)塊和可復(fù)用的頁面保存為模版:
我們可以在編輯器頁面輕松將頁面保存為模版, 并自動生成海報封面:
基于網(wǎng)頁生成封面的方式也很簡單, 我這里采用的是 dom-to-image 這個庫, 當然搭建也可以使用html2canvas。
表單設(shè)計器 & 數(shù)據(jù)收集分析能力
表單編輯器的實現(xiàn)思路我之前也寫過一些分享, 這里和大家再介紹一下核心的一些思路。
動態(tài)表單開發(fā)的一般思路
「1. 靜態(tài)化配置列表」
靜態(tài)化配置列表是最傳統(tǒng)的表單配置方式之一,基本思路就是利用母表來生成配置項,進而實現(xiàn)表單配置。類似于以下方式:
早期的網(wǎng)站配置就是類似于這種呢方案實現(xiàn)的,比如說我們要定制網(wǎng)站的主色,網(wǎng)站某些組件是否可見,是一種比較簡單的方式。但是缺點是每增加一個配置屬性,都要開發(fā)人員重新編寫一個字段配置代碼,這種方式在表單開發(fā)中非常不靈活,而且對代碼層有強依賴性,所以只適合做小型配置系統(tǒng)。比如個人網(wǎng)站,簡單的自定義表單。
「2. 基于json schema的動態(tài)表單配置」
基于「json schema」的動態(tài)表單配置有兩種實現(xiàn)方案, 一種就是支持在線修改json文件從而實現(xiàn)定制化,另一種就是完全無代碼操作,但是前提都需要提供一套通用的表單模版。類似于如下案例:
此種方案可以實現(xiàn)基本的表單自治。也是本文主要實現(xiàn)的方案。至于在線編寫json文件的方案。筆者之前也也過成熟的方案,具體可以參考:基于jsoneditor二次封裝一個可實時預(yù)覽的json編輯器組件(react版)。
「3. 支持在線coding的混合式表單設(shè)計」
支持「在線編程」的混合式表單設(shè)計方案是終極方案,也是目前流行的無代碼化平臺的思想之一。一方面它提供了基于「json schema」的動態(tài)表單配置, 對于一些強定制的,需要在線設(shè)計組件方案的模式,采用在線編程,實時打包成動態(tài)組件的方式,最后根據(jù)平臺的組件約定來實現(xiàn)組件庫的方式。如下圖所示:
在線代碼編輯可以使用「react-codemirror2」或者 「react-monaco-editor」插件來實現(xiàn)。至于在線打包,我們用「nodejs」完全可以實現(xiàn),筆者在做「Dooring」項目的在線下載代碼時就用到了該方案,感興趣的可以了解一下。
可視化領(lǐng)域中的表單引擎
可視化領(lǐng)域一方面強調(diào)的是圖形(可視化)的設(shè)計,一方面是動態(tài)表單。比如說我們想傻瓜式的改變一張圖的數(shù)據(jù),屬性,交互等,我們需要通過表單這一橋梁來實現(xiàn):
所以我們需要設(shè)計一款適合公司產(chǎn)品的“表單引擎”,來動態(tài)根據(jù)圖形組件的類型渲染不同表單配置。這塊思想也是表單設(shè)計器要解決的問題之一。在下面的文章中我們會詳細介紹實現(xiàn)過程。
從零實現(xiàn)一款動態(tài)表單設(shè)計器
在實現(xiàn)表單設(shè)計器之前,我們先來整理一下思路和需求。在筆者的最初草圖中,它長這樣:
從草圖中我們可以提取到如下任務(wù)信息:
- 定義一套表單組件庫
- 確定表單全局屬性配置
- 實現(xiàn)表單操作curd(增刪查改)
我們這里總結(jié)了幾個常用的表單組件如下:
- 單選框
- 復(fù)選框
- 單行文本
- 多行文本
- 下拉框
- 文件上傳
- 日期框
- 數(shù)值輸入框
以上這些基本滿足我們的日常開發(fā)需求,其次我們還可以開發(fā)數(shù)據(jù)源表單組件,列表組件,比如dooring實現(xiàn)的那樣:
類似的還有顏色面板這些,我們可以更具業(yè)務(wù)需求自行定制。
在完成表單組件庫之后,我們就需要根據(jù)配置項動態(tài)渲染了。也有兩種實現(xiàn)思路,一種就是類似于多條件判斷,如下:
{
item.type === 'Number' &&
}
{
item.type === 'Text' &&
}
{
item.type === 'TextArea' &&
}
這樣做雖然可行,也有很多成熟系統(tǒng)采用該方案,但是一旦表單變多,比如一個頁面有幾十個甚至上百個表單項,那么我們將渲染「m」 *** n**次(m為表單組件類型數(shù),n為配置項個數(shù))。另一種方式筆者看來是比較優(yōu)雅的,可以將復(fù)雜度降低到O(n),也就是筆者常用的對象法。思路大至如下:「將表單組件的類型作為對象的屬性,屬性值為對應(yīng)的表單組件,這樣遍歷的時候只需要對應(yīng)上對象的具體類型即可?!?nbsp;代碼如下:
// 維護表單控件, 提高form渲染性能
const BaseForm = {
"Text": (props) => {
const { label, placeholder, onChange } = props
return |
},
"Number": (props) => {
const { label, placeholder, onChange } = props
return |
}
}
// 動態(tài)渲染表單
{
formData.map((item, i) => {
let FormItem = BaseForm[item.type]
return
})
}
是不是很優(yōu)雅呢?后期我們只需要在「BaseForm」里維護表單組件即可,而且還可以基于「BaseForm」對表單進行包裝,實現(xiàn)動態(tài)刪除,編輯等功能。如下:
包裝后的代碼如下:
接下來我們看看表單的全局屬性,通過實際分析我們
標題名稱:如何評價Dooring低代碼/零代碼搭建平臺?
URL地址:http://m.5511xx.com/article/cccsjeo.html


咨詢
建站咨詢
