伴隨著5G時代的來臨，在移動互聯(lián)網(wǎng)領域以及物聯(lián)網(wǎng)領域都會有更多場景和交互需要呈現(xiàn)，5G通信將使前沿技術逐漸整合到前端開發(fā)中，未來更多的社會應用場景將實現(xiàn)數(shù)據(jù)化、智能化，所以未來前端會觸及到更多的應用場景同時展現(xiàn)給用戶更多能看到感受到的信息。
作者：姚丹丹
單位：中國移動杭州研發(fā)中心
上一期
Labs帶大家認識了
5G技術的更多可能性
那這期我們就搞搞別的技術？
......
俗話說得好
程序員千萬不要和產(chǎn)品經(jīng)理聊天
因為天聊完了
產(chǎn)品的需求有了
你的代碼在哪里？
● 表單引擎@and/engine ●
表單引擎@and/engine的出現(xiàn)終于改變了這種局面。程序員終于可以愉快地和產(chǎn)品聊天了。
產(chǎn)品：我要在線接入合作伙伴
開發(fā)：OK
產(chǎn)品：我要合作伙伴的公司名稱、公司性質(zhì)、營業(yè)執(zhí)照、銀行開戶許可、業(yè)務相關資質(zhì)。。。。
開發(fā)：OK
產(chǎn)品：公司名稱不能有特殊字符、公司性質(zhì)只能選擇、營業(yè)執(zhí)照要png圖片、銀行開戶許可可以是PNG或者JPG且不能超過2M。。。。。
開發(fā)：OK
產(chǎn)品：好的你給我評估一下開發(fā)時間
開發(fā)：好了，你看一下是否符合你的需求
產(chǎn)品：What??
下面來看一下這如高鐵一般的開發(fā)速度：
配置化開發(fā)演示
用引擎開發(fā)的和家親生態(tài)合作平臺
只要寫一份描述性的json格式配置文件，頁面布局、業(yè)務邏輯、校驗條件、聯(lián)動效果、用戶交互提示都有了，開發(fā)者完全不用關心底層實現(xiàn)，原來至少需要開發(fā)一天的頁面，幾分鐘就能配置出來。我們是怎么實現(xiàn)這樣極速的開發(fā)體驗的呢？因為我們有自研表單引擎@and/engine，表單引擎是如何實現(xiàn)通過配置文件直接生成可交付的頁面的呢？引擎所需的配置文件主要分為3個部分，schema(描述頁面整體結(jié)構(gòu))，components(描述所需組件列表及屬性)，conditions(描述聯(lián)動條件)。引擎首先會解析schema結(jié)構(gòu)，schema只包含id和children兩個關鍵字，組件之間可以通過children進行無限的任意嵌套來表示復雜的頁面布局，引擎遍歷schema結(jié)構(gòu)遞歸渲染出整體布局，第二步利用components中的組件屬性、conditions中的聯(lián)動條件以及初始化數(shù)據(jù)initModels計算首次渲染所需數(shù)據(jù)，計算后的數(shù)據(jù)傳遞給所有組件進行最終渲染，下面是表單引擎首次渲染的實現(xiàn)流程：
表單引擎渲染流程
當用戶進行輸入操作時，引擎通過全局的重新計算和重渲染來實現(xiàn)組件內(nèi)容校驗、錯誤提示、組件之間聯(lián)動等等，最初的數(shù)據(jù)處理流程如下：
數(shù)據(jù)處理流程
但是當我們開發(fā)一個比較復雜的頁面時，很快出現(xiàn)了問題，開發(fā)速度是飛快，但是用戶的體驗就沒有那么絲滑了，當用戶每次在表單中輸入內(nèi)容時，引擎為了實現(xiàn)動態(tài)聯(lián)動和實時校驗，會重新計算整體數(shù)據(jù)并傳遞給所有組件，所有組件在接收到新數(shù)據(jù)后會觸發(fā)重渲染，而大量渲染是非常損耗瀏覽器性能的，用戶操作起來可以說是一步一卡。
由引擎智能生成的頁面和傳統(tǒng)方式開發(fā)的頁面最大的區(qū)別在于，傳統(tǒng)開發(fā)是針對某一個具體頁面進行的，開發(fā)者可根據(jù)業(yè)務關系知道哪些組件之間是有關聯(lián)的，組件的重渲染行為可以根據(jù)具體的業(yè)務關系來編寫，但引擎是無法預知組件之間的動態(tài)關聯(lián)關系的，某些組件的屬性支持配置函數(shù)，也就是只有在數(shù)據(jù)流的終點”組件層”才能確切地知道改變后的數(shù)據(jù)。為了保證全局的實時校驗和動態(tài)聯(lián)動，每個組件都需要監(jiān)聽全局數(shù)據(jù)，一旦全局數(shù)據(jù)中有一部分發(fā)生改變就會傳遞給所有組件，這樣就導致了冗余的重渲染，當頁面組件較多或者組件內(nèi)容較復雜時用戶就會感覺到明顯的卡頓。
高效的智能化開發(fā)是我們想要的，絲滑的用戶體驗也是我們想要的。理想的狀態(tài)是每個組件既可以監(jiān)聽到全局數(shù)據(jù)的變化，但又只在自身數(shù)據(jù)受影響時進行重渲染，也就是每個組件既要耳聽八方，又要無視無關組件，聽起來似乎是很矛盾的一件事，優(yōu)化一度陷入了僵局，但是我們最終做到了。
既然重渲染才是瀏覽器的性能殺手，那么我們就可以將渲染行為獨立出來，把原來的組件轉(zhuǎn)化為純渲染組件，在每一個組件外包裹一層獨立數(shù)據(jù)校驗層，所有的數(shù)據(jù)改變經(jīng)過統(tǒng)一計算層計算后會首先傳遞給數(shù)據(jù)校驗層，該層只做數(shù)據(jù)的接收、計算、比較，計算后如果發(fā)現(xiàn)本組件前后數(shù)據(jù)不一致才傳遞給真正的組件渲染層進行渲染，如果前后數(shù)據(jù)一致則忽略此次改變。這樣我們就實現(xiàn)了組件之間的任意聯(lián)動效果并且只發(fā)生最小重渲染。新的數(shù)據(jù)流圖如下：
優(yōu)化后的數(shù)據(jù)處理流程
優(yōu)化后的引擎已經(jīng)可以做到開發(fā)速度和用戶體驗齊飛，都如絲般順滑。當表單引擎逐漸應用到項目組的所有項目，并趨于穩(wěn)定后，我們又不滿足于現(xiàn)狀了，因為除了表單頁我們還有千萬種頁面需求，既然表單可以配置化開發(fā)，那其他頁面是否也可以配置化開發(fā)？因為表單對于引擎來說只是預置的組件而已，同樣的機制我們可以應用到所有組件，另外，我們既然做到了配置化開發(fā)，是否可以進一步做到0開發(fā)，直接可視化生成頁面？想想都有點激動呢。
于是我們提取了引擎核心部分，也就是結(jié)構(gòu)渲染層、計算層、獨立數(shù)據(jù)校驗層，將組件層徹底解耦，同時開放接入組件的方法useComponent,獨立出一個可插拔組件的核心引擎，這樣底層的組件就可以根據(jù)業(yè)務需求隨意替換了，比如運營類頁面需要比較多的圖片和視頻，就可以使用useComponent接入圖片模塊和視頻模塊生運營引擎；數(shù)據(jù)可視化頁面需要較多的圖表也可以使用useComponent接入圖表模塊生成可視化引擎。
不同的模塊需要不同的配置項，如圖片模塊需要上傳圖片和跳轉(zhuǎn)鏈接，視頻模塊除了上傳視頻可能還需要自定義背景和封面等等，每個模塊只要增加一個string類型的字段存儲轉(zhuǎn)換后的json配置文件即可基于表單引擎渲染出一個獨立的配置頁面。
表單引擎和運營引擎組合即可快速搭建一個可視化運營搭建系統(tǒng)。最終我們基于表單引擎孵化的可視化運營搭建系統(tǒng)LEGO是這樣的：
可視化編輯器
用編輯器生成的頁面是這樣的：
LEGO系統(tǒng)上線一個月內(nèi)已為智能組網(wǎng)平臺搭建了30多個運營頁面，服務裝維人員十萬余人，而開發(fā)和測試投入都是0，真正實現(xiàn)了0開發(fā)。從普通開發(fā)到配置化開發(fā)，到最后的0開發(fā)，表單引擎就是這樣讓前端開發(fā)速度飛起來的。
