<ins id="hb7xp"></ins>
<cite id="hb7xp"></cite>
<var id="hb7xp"></var>
<address id="hb7xp"><menuitem id="hb7xp"><i id="hb7xp"></i></menuitem></address>
<cite id="hb7xp"></cite><menuitem id="hb7xp"></menuitem>
<var id="hb7xp"></var><cite id="hb7xp"><video id="hb7xp"></video></cite>
<cite id="hb7xp"></cite>
<var id="hb7xp"></var>
<var id="hb7xp"></var><cite id="hb7xp"></cite><var id="hb7xp"></var>
<del id="hb7xp"><span id="hb7xp"><menuitem id="hb7xp"></menuitem></span></del><var id="hb7xp"><video id="hb7xp"><thead id="hb7xp"></thead></video></var>

C114通信網  |  通信人家園

技術
2021/4/23 19:26

五分鐘技術趣談 | 表單引擎@and/engine是如何讓前端開發飛起來的?

移動labs  

導讀:伴隨著5G時代的來臨,在移動互聯網領域以及物聯網領域都會有更多場景和交互需要呈現,5G通信將使前沿技術逐漸整合到前端開發中,未來更多的社會應用場景將實現數據化、智能化,所以未來前端會觸及到更多的應用場景同時展現給用戶更多能看到感受到的信息。

作者:姚丹丹

單位:中國移動杭州研發中心

●  表單引擎@and/engine  ●

表單引擎@and/engine的出現終于改變了這種局面。程序員終于可以愉快地和產品聊天了。

產品:我要在線接入合作伙伴

開發:OK

產品:我要合作伙伴的公司名稱、公司性質、營業執照、銀行開戶許可、業務相關資質。。。。

開發:OK

產品:公司名稱不能有特殊字符、公司性質只能選擇、營業執照要png圖片、銀行開戶許可可以是PNG或者JPG且不能超過2M。。。。。

開發:OK

產品:好的你給我評估一下開發時間

開發:好了,你看一下是否符合你的需求

產品:What??

 

下面來看一下這如高鐵一般的開發速度:

配置化開發演示

配置化開發演示

用引擎開發的和家親生態合作平臺

用引擎開發的和家親生態合作平臺

只要寫一份描述性的json格式配置文件,頁面布局、業務邏輯、校驗條件、聯動效果、用戶交互提示都有了,開發者完全不用關心底層實現,原來至少需要開發一天的頁面,幾分鐘就能配置出來。我們是怎么實現這樣極速的開發體驗的呢?因為我們有自研表單引擎@and/engine,表單引擎是如何實現通過配置文件直接生成可交付的頁面的呢?引擎所需的配置文件主要分為3個部分,schema(描述頁面整體結構),components(描述所需組件列表及屬性),conditions(描述聯動條件)。引擎首先會解析schema結構,schema只包含id和children兩個關鍵字,組件之間可以通過children進行無限的任意嵌套來表示復雜的頁面布局,引擎遍歷schema結構遞歸渲染出整體布局,第二步利用components中的組件屬性、conditions中的聯動條件以及初始化數據initModels計算首次渲染所需數據,計算后的數據傳遞給所有組件進行最終渲染,下面是表單引擎首次渲染的實現流程:

表單引擎渲染流程

表單引擎渲染流程

當用戶進行輸入操作時,引擎通過全局的重新計算和重渲染來實現組件內容校驗、錯誤提示、組件之間聯動等等,最初的數據處理流程如下:

數據處理流程

數據處理流程

但是當我們開發一個比較復雜的頁面時,很快出現了問題,開發速度是飛快,但是用戶的體驗就沒有那么絲滑了,當用戶每次在表單中輸入內容時,引擎為了實現動態聯動和實時校驗,會重新計算整體數據并傳遞給所有組件,所有組件在接收到新數據后會觸發重渲染,而大量渲染是非常損耗瀏覽器性能的,用戶操作起來可以說是一步一卡。

由引擎智能生成的頁面和傳統方式開發的頁面最大的區別在于,傳統開發是針對某一個具體頁面進行的,開發者可根據業務關系知道哪些組件之間是有關聯的,組件的重渲染行為可以根據具體的業務關系來編寫,但引擎是無法預知組件之間的動態關聯關系的,某些組件的屬性支持配置函數,也就是只有在數據流的終點”組件層”才能確切地知道改變后的數據。為了保證全局的實時校驗和動態聯動,每個組件都需要監聽全局數據,一旦全局數據中有一部分發生改變就會傳遞給所有組件,這樣就導致了冗余的重渲染,當頁面組件較多或者組件內容較復雜時用戶就會感覺到明顯的卡頓。

高效的智能化開發是我們想要的,絲滑的用戶體驗也是我們想要的。理想的狀態是每個組件既可以監聽到全局數據的變化,但又只在自身數據受影響時進行重渲染,也就是每個組件既要耳聽八方,又要無視無關組件,聽起來似乎是很矛盾的一件事,優化一度陷入了僵局,但是我們最終做到了。

既然重渲染才是瀏覽器的性能殺手,那么我們就可以將渲染行為獨立出來,把原來的組件轉化為純渲染組件,在每一個組件外包裹一層獨立數據校驗層,所有的數據改變經過統一計算層計算后會首先傳遞給數據校驗層,該層只做數據的接收、計算、比較,計算后如果發現本組件前后數據不一致才傳遞給真正的組件渲染層進行渲染,如果前后數據一致則忽略此次改變。這樣我們就實現了組件之間的任意聯動效果并且只發生最小重渲染。新的數據流圖如下:

優化后的數據處理流程

優化后的數據處理流程

優化后的引擎已經可以做到開發速度和用戶體驗齊飛,都如絲般順滑。當表單引擎逐漸應用到項目組的所有項目,并趨于穩定后,我們又不滿足于現狀了,因為除了表單頁我們還有千萬種頁面需求,既然表單可以配置化開發,那其他頁面是否也可以配置化開發?因為表單對于引擎來說只是預置的組件而已,同樣的機制我們可以應用到所有組件,另外,我們既然做到了配置化開發,是否可以進一步做到0開發,直接可視化生成頁面?想想都有點激動呢。

于是我們提取了引擎核心部分,也就是結構渲染層、計算層、獨立數據校驗層,將組件層徹底解耦,同時開放接入組件的方法useComponent,獨立出一個可插拔組件的核心引擎,這樣底層的組件就可以根據業務需求隨意替換了,比如運營類頁面需要比較多的圖片和視頻,就可以使用useComponent接入圖片模塊和視頻模塊生運營引擎;數據可視化頁面需要較多的圖表也可以使用useComponent接入圖表模塊生成可視化引擎。

不同的模塊需要不同的配置項,如圖片模塊需要上傳圖片和跳轉鏈接,視頻模塊除了上傳視頻可能還需要自定義背景和封面等等,每個模塊只要增加一個string類型的字段存儲轉換后的json配置文件即可基于表單引擎渲染出一個獨立的配置頁面。

表單引擎和運營引擎組合即可快速搭建一個可視化運營搭建系統。最終我們基于表單引擎孵化的可視化運營搭建系統LEGO是這樣的:

可視化編輯器

可視化編輯器

用編輯器生成的頁面是這樣的:

LEGO系統上線一個月內已為智能組網平臺搭建了30多個運營頁面,服務裝維人員十萬余人,而開發和測試投入都是0,真正實現了0開發。從普通開發到配置化開發,到最后的0開發,表單引擎就是這樣讓前端開發速度飛起來的。

給作者點贊
0 VS 0
寫得不太好

免責聲明:本文僅代表作者個人觀點,與C114通信網無關。其原創性以及文中陳述文字和內容未經本站證實,對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾,請讀者僅作參考,并請自行核實相關內容。

熱門文章
    最新視頻
    為您推薦

      C114簡介 | 聯系我們 | 網站地圖 | 手機版

      Copyright©1999-2021 c114 All Rights Reserved | 滬ICP備12002291號

      C114 通信網 版權所有 舉報電話:021-54451141

      亚洲熟伦熟女专区_重生汉末睡了皇后_隔壁邻居波多野结衣在线播放_男人女人免费啪啪观看_大炕上各弄各的_夜夜被两个男人玩得死去活来