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