簡介
飛碼是京東科技平臺研發部研發的低程式碼產品，可使營銷運營域下web頁面快速搭建。本文將從三個方面來講解如何便捷配置出頁面，第一部分從資料、事件、業務支援三個方面進行分析，第二部分從模板與頁面收藏與升級、頁面UI結構、畫布功能三個方面進行分析，第三部分從監控、頁面配置、頁面資料匯入匯出以及其他能力四個方面進行分析。
一、第一部分：資料、事件、業務支援
1、資料設計
飛碼LowCode前端技術（一）種對資料結構進行了分析，飛碼是資料驅動+事件驅動，在編輯態配置區域需要頁面中各種資料（介面出參、元件出參、頁面入參、業務邏輯資料）。該部分僅說明飛碼如何實現配置邏輯與規則的，如何實現資料驅動會在後續小節說明。
資料複用：一個元件的入參是固定值，例如select1元件list是一個固定值1，select2元件list也是一個固定值1，這個就需要資料的複用能力。飛碼解決方案詳見圖1
圖1
資料配置：資料配置包含了資料A與資料B之間是賦值關係、邏輯判斷關係，還是組合關係。結合業務實際情況，飛碼歸納常見的資料配置情況。詳見圖2
圖2
對任何一個可配置的元件屬性值，均可以透過全域性資料視角進行配置。資料來源是出參，設定資料是給某個元件或Api，彈框等設定資料。當我們需要處理複雜的業績時，可以透過處理函式進行快速處理。飛碼中的函式是常見的js函式，飛碼也內建了form表單的校驗函式，form校驗規則也可以進行復用。該部分在事件小節說明。飛碼支援用全域性視角看頁面的所有資料情況以及流轉情況。
資料匯入：頁面配置過程需要看到頁面中所有資料欄位及資料層級結構，飛碼認為有四種方案可以選擇。一是對元件進行一一配置；二是先配置頁面之後在元件中進行選擇；三是透過元件id自動生成元件關聯屬性，之後與介面進行一一配對；四是元件與頁面均可以配置，配置之後具有一致性。飛碼使用方案四，可以元件層面進行關聯欄位配置，也可以頁面進行配置。在實際搭建頁面的情況下，發現頁面級別的匯入資料更為便捷。飛碼目前也支援j-api、bff與元件關聯之後進行匯入能力。頁面級別的資料欄位匯入詳見圖3
圖3
結合j-api可以透過介面資料直接生成頁面的一部分，並實現元件欄位與頁面欄位一致性。詳見圖4
圖4
2、事件設計
飛碼對事件進行了分類，分為導航、元件顯示&隱藏&禁用、資料、彈框&toast、操作、form操作、其他。如圖5所示為事件編排區域。飛碼中事件也支援配置，圖5右側區域為單事件節點的例項配置。每一個事件透過JSON配置實現（飛碼lite版配置），支援動態載入額外新增事件。
圖5
飛碼對常見事件進行提取歸類，列舉如圖5中左側區域。透過編排方式進行業務配置。
事件配置：元件、頁面生命週期、其他事件呼叫情況會使用事件。建立事件之後飛碼會在快取中記錄事件id以及事件名稱與相關的事件編排。研發可以在元件事件、頁面事件、其他事件中進行配置。飛碼編輯態事件流程如圖6所示。
圖6
事件與資料打通：如圖2所示，飛碼支援在事件中進行資料的配置，例如messag中（如圖7），點選js編輯器會喚醒圖2，之後可以配置messag的提示語，提示語來自介面，飛碼使用$api開頭，介面id為其屬性值，之後一級一級找錯誤資訊即可。
圖7
事件的複用：飛碼支援事件A，呼叫事件B，事件B呼叫事件C。也支援事件A根據配置的邏輯規則呼叫自己。
事件的序列與並行：飛碼事件編排中任何一個節點的輸出點支援作為多個事件節點的輸入點。遇到多個事件同時觸發的時候，可以實現事件的並行與序列執行。
問題：事件編排錯誤會導致事件死迴圈怎麼解？
事件死迴圈一般是由於條件邏輯書寫錯誤導致的，ProCode開發過程中也會遇到類似情況，方法A呼叫了方法B，方法B又呼叫了方法A，一直迴圈呼叫。常規配置導致的死迴圈飛碼FMHelper會幫助監測到，當研發書寫js導致的死迴圈飛碼執行態FMHelper會最大能力監測，由於執行態資料未知性，部分死迴圈監測不到。該部分後續會加強邏輯處理。
3、業務支援設計
飛碼的業務支援中，有許可權與埋點。為了便捷研發搭建頁面飛碼增加了常見函式支援。
許可權設計：已元件與頁面維度，許可權可以分為不可見與不可互動兩種情況。A使用者沒有許可權看到a元件（或者頁面），B使用者沒有許可權對a元件（或者頁面）進行互動，C使用者可以看到a元件（或者頁面）並可以互動。
飛碼許可權依賴京東科技統一許可權系統，實現流程如圖8所示。
圖8
考慮安全節省頻寬，對隱藏頁面或者元件，飛碼服務不會下發相應的DSL到飛碼的執行態。
埋點設計：接入公司內部奇點平臺，飛碼對埋點進行分類。分為元件型別埋點（含曝光），與事件型別埋點。流程詳見圖9
圖9
飛碼對元件，頁面，事件的埋點方案，是透過配置化實現的。大大降低了理解成本與跨平臺配置成本。
函式便捷配置能力：上一個章節中提到飛碼官方提供的常見函式，常見函式處理列舉情況。該部分主要便捷研發書寫js函式。
問題：函式是不是具備動態擴充套件能力？
函式與元件不太一樣，常見的函式已全部列舉到飛碼。飛碼之前思考過透過飛碼後管動態下發函式能力，發現實際使用場景並不多。目前飛碼不支援動態擴充套件函式能力。後續依據情況是否增加函式動態擴充套件能力。
小結
本小節分析了飛碼如何便捷配置出頁面，分別對資料、事件、業務支援方面進行了詳細介紹。資料配置、事件配置均可以透過全域性視角看到整個頁面相關資料結構與邏輯結構。業務支援方面最大限度的實現配置化，同時也支援函式配置，大大減少了研發書寫js時間成本。
第二部分：模板與頁面收藏與升級、頁面UI結構、畫布功能
1、模板與頁面收藏升級設計
模板收藏與升級：在飛碼LowCode前端技術（二）章節中對模板的收藏進行了說明。飛碼模板（包括官方模板）可以進行升級，編輯。飛碼對模板分類以及升級流程方案詳見圖10
圖10
當使用者收藏模板之後，可以在飛碼管理端進行編輯，編輯之後飛碼服務端會更新對應的模板DSL。飛碼沒有對模板的版本進行管理，模板的使用是一個快照，當研發使用者拖動模板到編輯頁面的時候，會對模板中元件id進行更新。飛碼的模板DSL與飛碼頁面DSL保持一致，詳見飛碼LowCode前端技術（一）。
頁面收藏與升級：飛碼的頁面收藏能力在飛碼後管進行操作，飛碼頁面的收藏是一個快照。搭建頁面期間會遇到很多類似的頁面，這樣就可以透過頁面收藏，之後在進行編輯。頁面收藏邏輯詳見圖2
圖11
頁面收藏之後在使用頁面的時候會建立一個頁面快照，生成一個新頁面id。頁面收藏，個人頁面收藏同時也是快手的收藏。當官方頁面、個人頁面變化的時候，之前收藏的頁面不會發生變化。
問題：是不是對模板與頁面增加版本號？之後根據版本號進行選擇性配置。
飛碼之前考慮過模板與官方頁面都有版本號進行控制，在使用階段發現版本號的選擇與理解會增加使用者心智負擔。在web頁面中複用的模板與頁面並不太多，飛碼暫時沒有模板與頁面模板版本號，後續業務根據情況考慮是否增加。
2、頁面UI結構設計
頁面UI結構，飛碼用樹的形式實時展示。當畫布是頁面級編排的時候，UI結構是頁面級別的。當畫布是區域性檢視（開啟另外一個檢視，實現區域性放大能力，實現檢視的便捷配置）時候，UI結構是區域性檢視級別的。可以理解為UI結構與當前畫布中元件結構一一對應。如圖12
圖12
頁面UI資料結構在[飛碼LowCode前端技術（一）]中對資料結構進行了分析。飛碼在編輯態中資料結構進行了區分，分為頁面資料結構、區域性檢視資料結構。區域性檢視資料結構資料是快取資料，使用detailViewCanvas進行快取（如何與頁面資料結構結合，在畫布小節說明）。UI資料結構整體設計詳見圖13
圖13
編輯態的頁面UI資料結構與執行態（投產）是一致的。
3、畫布設計
畫布的詳細設計與技術實現詳見之後的章節，該小節側重描述畫布功能以及區域性檢視如何與主檢視結合的能力。
支援精準拖拽：詳見圖14
圖14
飛碼元件在佈局的時候對於目標元件進行上、右、下、左四個區域區分。實時監控滑鼠位置，之後對目標元件進行判斷。若支援子元件的元件中沒有元件，例如div，放入第一個元件的時候會顯示“裡”。詳見圖15所示
圖15
元件的拖拽會實時監控目標元件（包括是不是支援內部增加元件），滑鼠位置。具體演算法邏輯會在後續章節中進行說明。
上下移動複製刪除：
圖15可以看出，飛碼畫布會對選中元件實時監控父級與兄弟元件，進而確定是否支援上下移動。飛碼元件複製是對元件以及子元件完全複製，包括子元件中配置的事件或者資料。
特定元件擴充套件特定能力：
飛碼認為form元件，table元件，為複雜型別元件。飛碼認為複雜元件的配置便捷性需要挨著元件區域最近的地方，最大能力提升便捷性。
對form元件，經常配置內部元件佈局。詳見圖16
圖16
對table元件，經常配置內部元件佈局。詳見圖17
圖17
飛碼對table中的元件進行了列的拖拽排序，prop與labe的快速設定，快速增加一列能力。同時飛碼對table元件與右側配置表單進行了繫結，實現快速定位能力。
問題：飛碼對元件便捷區3個點(…)是否支援遠端元件下發的時候一起下發對應能力？
飛碼對該部分能力還沒有開放，目前僅支援官方元件的能力擴充套件。後續根據實際業務場景考慮是否開放該部分能力。
複雜區域配置應支援區域性畫布：
圖16中el-table-column區域配置多個按鈕的時候，點選該區域內的小方塊，會喚起區域性檢視。區域性檢視中與頁面畫布功能完全一致。可以隨意對元件進行組合。在[飛碼LowCode前端技術（一）]中介紹了飛碼彈框是透過一個陣列進行管理的。透過彈框的資料結構可以看出，每一個彈框是一個區域性檢視，透過事件喚起彈框。
區域性檢視如何與主檢視結合：
飛碼將區域性檢視劃分為兩種：一是彈框類（包含Dialog，drawer），二是元件類（目前包含table、tabs）
第一類：彈框是透過事件觸發的，於是飛碼事件編排中選擇對應的彈框即可。在資料結構中彈框與事件有關，與頁面無關。
第二類：該部分在頁面或者彈框內，與常規資料結構一樣，透過children欄位表示。
小結
本小節分析了飛碼如何便捷配置出頁面-3，分別對模板與頁面收藏與升級、頁面UI結構、畫布功能三個方面進行了詳細介紹。飛碼的UI結構設計、畫布設計符合常規設計模式，對彈框進行了統一管理。
第三部分：監控、頁面配置、頁面資料匯入匯出以及其他能力
1、監控（FMHelper）設計
飛碼監控需要做兩件事情，一是編輯態怎麼幫助搭建人員快速定位問題並給出可能出現的問題點，二是在執行態最大能力定位問題（該部分還在研發中）。本節僅講述編輯態中如何設計與定位問題的。飛碼對FMHelper劃分四部分分別是頁面、彈框、事件、API。詳見圖18
圖18
FMHelper在編輯態時會對整個頁面的DSL進行監測，依據搭建中常見錯誤資訊進行彙總分類，並形成配置表。配置表部分會在下一章節進行說明。飛碼將問題分為error與warn兩個級別。詳見圖19
圖19
飛碼依據頁面中所有配置項以及事件鏈路關係，對於大部分問題都可以定位到錯誤配置位置，點選檢視即可。
2、頁面配置設計
飛碼頁面配置分為樣式、事件、資料、配置共4部分組成。詳見圖20所示。
圖20
事件：頁面事件與vue頁面生命週期函式一一對應，飛碼同時支援在一個生命週期函式中配置多個事件。選擇相關的事件，即可在執行態的時候呼叫相關事件。
資料：資料分為入參配置，出參配置。入參配置的時候配置一個schema或者配置一些鍵值對，頁面在執行態的時候會實時監控入參引數的變化，同時頁面中的其他元件存在依賴關係的也會發生先關變化。出參配置這部分能力已轉移到事件編排，在頁面配置區域目前禁用狀態，後續飛碼會對其隱藏。詳見圖21。
圖21
飛碼頁面入參有2種情況，一是透過飛碼對外提供的sdk，標籤引入之後對inData進行設定。二是會取投放出去頁面的url中的引數。詳見圖22
圖22
配置：該區域是頁面業務型配置，包含整個頁面API的host，API返回正確的code碼，埋點與許可權。詳見圖23所示
圖23
頁面在環境切換情況下，只需要在頁面配置->配置 進行相關配置即可。
3、頁面資料匯入匯出設計
測試環境、預發環境、線上環境對應的服務是不一樣的。測試環境的資料無法同步到預發環境。測試環境除錯好的頁面，如何在預發環境上快速上線？飛碼透過匯出、匯入能力實現頁面的快速複製能力。如圖24
圖24
匯出：會對頁面整個資料結構進行資料加工，去掉空欄位，刪除事件編排中無用欄位。
匯入：與匯出相反，會對整個匯入的DSL資料結構進行加工，增加必備欄位，增加事件編排中必備欄位。
4、其他能力設計
回退上一步：在實踐中發現畫布拖拽（元件移動、兄弟元件之間的佈局等）之後並不是想要的效果，飛碼提供了一鍵回退能力，如圖7所示“畫布 上一步（4）“，飛碼僅支援回退5步操作。詳見圖25
圖25
問題：為什麼僅支援5步回退？
搭建頁面期間畫布誤操作情況一般是1-2步，飛碼設計5步並沒有考慮回退太多步驟的情況，其中5也是配置的一個數字。可以修改，支援更多步。
歷史記錄：操作儲存、預覽按鈕的時候，飛碼會記錄當前頁面DSL資訊，記錄在服務伺服器。效果圖見圖26
圖26
點選放大按鈕可以看到點選儲存、預覽按鈕時候的截圖。點選“應用到當前頁面“，可以切換到之前的歷史版本。點選”複製DSL“，可以複製歷史版本的DSL，之後開發其他頁面使用或者對DSL進行對比。
預覽：點選“預覽“按鈕之後，即可對當前頁面進行預覽，會跳轉到飛碼執行態頁面。目前飛碼FMHelper還沒有對不合格（配置有問題）的頁面進行攔截，飛碼對FMHelper定位是一個提示工具。隨著FMHelper能力變強，在智慧監測與校驗方面給頁面搭建賦能。
問題：飛碼測試環境預、發環境與線上環境在存量頁面中怎麼對比DSL的區別？
測試環境伺服器無法與預發、線上打通。飛碼目前支援預發環境與線上環境DSL的對比以及頁面配置對比，在預發環境除錯好的頁面，線上上環境只需要同步即可。也可對同步的內容進行編輯。
本小節分析了飛碼如何便捷配置出頁面-4，分別對監控、頁面配置、頁面資料匯入匯出以及其他能力四個方面進行了詳細介紹。FMHelper是飛碼的一個輔助工具，幫助搭建人員快速定位問題、頁面配置目的是在執行環境不一致的情況下對變數引數進行快速設定，資料匯入匯出解決了環境資料不同步問題以及提供頁面快速複製能力。下章節介紹飛碼LowCode前端技術：如何便捷快速驗證實現投產及飛碼探索。
作者：京東科技 王光輝
來源：京東雲開發者社群 轉載請註明來源