前段時間，袋鼠云離線開發(fā)產(chǎn)品接到改造數(shù)據(jù)同步表單的需求。

一方面，數(shù)據(jù)同步模塊的代碼可讀性和可維護性較差，導致在數(shù)據(jù)同步模塊開發(fā)新功能和定位問題的效率很低。另一方面，整體規(guī)劃上，希望在對接新的數(shù)據(jù)源時，可以不再關心表單渲染相關問題，從數(shù)據(jù)源中心新建數(shù)據(jù)源一直到數(shù)據(jù)源在數(shù)據(jù)同步模塊的應用，全鏈路的表單都可以通過配置化的方式解決。

本文就將以此為例，拋磚引玉，為大家詳細介紹配置式表單渲染器實現(xiàn)的實踐之路。

數(shù)據(jù)同步表單背景

數(shù)據(jù)同步模塊整體上分為四個部分，數(shù)據(jù)來源表單、同步目標表單、字段映射組件和通道控制表單。

其中前三個部分對應的代碼非?；靵y，代碼量也很大，單個組件代碼 5000+ 行，這里著重說一下數(shù)據(jù)來源表單和同步目標表單。

數(shù)據(jù)來源和同步目標表單的主要功能是收集數(shù)據(jù)源對應的配置信息，并且根據(jù)數(shù)據(jù)源類型的不同，對應需要渲染的表單項也不同。

目前袋鼠云離線開發(fā)產(chǎn)品 BatchWorks 數(shù)據(jù)同步功能的數(shù)據(jù)源多達50+種。在長時間的迭代過程中，日積月累出現(xiàn)了很多強行復用的代碼，這些強行復用的代碼內(nèi)部又包含著大量的 if else 邏輯。另外，數(shù)據(jù)同步模塊的表單內(nèi)部有很多聯(lián)動關系，比如：

· 某個表單項的值變化時，需要發(fā)起接口請求，請求的返回值被用作另一個表單項下拉框的數(shù)據(jù)

· 某個表單項的值變化時，需要去清空/重置其他一些表單項的值

· 某個表單項的值變化時，需要顯示/隱藏某個表單項

· 某個表單項的值變化時，某個表單項的 label 文案、表單項組件（比如從 select 變成 input ） 等隨之發(fā)生變化

這些表單項的聯(lián)動處理邏輯在代碼中混雜交叉，另外還要加上表單回顯的特殊邏輯處理，表單的值收集到 redux 的特殊邏輯處理等。

需求分析

基于上述需求背景，表單渲染器的核心功能是輸入一份配置，輸出表單 UI 組件。

基于上述數(shù)據(jù)同步表單背景，我們希望渲染器可以盡可能吸收掉表單內(nèi)部的復雜度，也就是說在表單的配置中要能夠描述上述的聯(lián)動關系，那么可以大概得出表單的配置需要描述：

· 表單項的基礎信息，比如字段名、label、表單組件、校驗信息等

· 表單項數(shù)據(jù)之間的聯(lián)動

· 表單項 UI 的聯(lián)動（控制顯示/隱藏）

· 表單項的值變化時需要觸發(fā)的副作用（比如調(diào)用接口）

表單基礎信息描述

這里配置格式使用 JSON 格式，用一個數(shù)組描述所有的表單項信息，UI 上表單項的渲染順序即配置數(shù)組中表單項配置的順序，表單組件使用 Ant Design Form。

對于表單項基礎信息的描述配置，大多可以直接搬用 Ant Design Form Item 的 props，比如 label、rules、Tooltip 等屬性，這里不多贅述。

比較特殊的是，需要在配置里描述表單項描述的 UI 組件，比如 Select、Input，那么這里使用 widget 字段去描述。另外，組件的描述除了組件名稱，還需要描述組件的 props， 所以還需要一個 widgetProps 字段去描述組件的屬性，比如 placeholder、disabled 等。

那么一個用于選擇數(shù)據(jù)源的表單項應該這樣描述：

當然可能會存在某些表單項的 UI 組件有自定義的情況，比如可編輯表格，代碼編輯器等。這個時候就需要開發(fā)自定義表單組件了，然后把這些組件注入到 FormRenderer 中，偽代碼如下所示：

那么目前的結構如圖所示：

這份配置寫到這里的時候，問題出現(xiàn)了：

· 無法在配置中描述 onChange、onSelect 等事件回調(diào)函數(shù)

· 相比于 jsx 強大的表達能力，JSON 中只能表達基本的數(shù)據(jù)結構，而沒辦法直接表達邏輯

· Select 下拉框的數(shù)據(jù)可能來源于接口，這種情況在業(yè)務中相當常見，這里也沒辦法表達

· 不能自定義表單校驗器，無法支持復雜的 Tootip 提示，比如帶有 a 標簽的 Tootip

上述問題產(chǎn)生的根本原因，實際上是 JSON 與 jsx 之間表達能力的差距。但是從另一個角度來講，正因為 JSON 的表達能力和靈活性不如 jsx，所以在用來描述 UI 時，JSON 更不容易導致混亂。

我們先思考如何表達 Select 下拉框的數(shù)據(jù)來源于接口，這里可以拆解為兩個部分，數(shù)據(jù)獲取和取得接口的返回值并在配置項中表達。

數(shù)據(jù)獲取

實際上，Select 下拉框中的數(shù)據(jù)也并不一定來源于接口，也可能是來源于其他業(yè)務數(shù)據(jù)，所以在配置項描述數(shù)據(jù)獲取時，不應該關心數(shù)據(jù)的來源。

很顯然，數(shù)據(jù)獲取邏輯需要用 js 描述 ，這里我們抽象出一個 Service 的概念，用于描述/聲明數(shù)據(jù)獲取邏輯，Service 的聲明使用 js，在 JSON 配置中，只需要去描述 Service 的調(diào)用邏輯即可。對于 JSON 配置來說， Service 調(diào)用需要三個要素：

· Service 的標識/名稱，表示哪一個 Service 被觸發(fā)

· Service 的觸發(fā)時機

· Service 返回的數(shù)據(jù)如何存儲

● Service 的觸發(fā)時機

Service 的觸發(fā)一般來說是由于用戶的交互引起的，當然也存在在表單項組件掛載時就需要觸發(fā)的情況，那么調(diào)用時機大概就是以下幾種：

· onMount

· onChange

· onSearch

· onFocus

· onBlur

● Service 返回的數(shù)據(jù)如何存儲

這里 Service 返回的數(shù)據(jù)存儲需要能被 UI 獲取到，那么需要將返回的數(shù)據(jù)都維護在 FormRender 內(nèi)部，這里將存儲數(shù)據(jù)的地方命名為 extraData。那么我們描述 Service 返回的數(shù)據(jù)的存儲，可以使用一個 fieldInExtraData 的字段，描述當前 Service 返回的數(shù)據(jù)被存儲在 extraData 的那個字段中，取值時：extraData[fieldInExtraData]。

那么在表單項配置中描述 Service，如下所示：

● Service 的聲明

對于 Service 本身來說，要做的事情就是獲取并處理數(shù)據(jù)然后返回，當然 Service 本身可能需要接受一些參數(shù)，比如當前 Form 收集到的數(shù)據(jù)、Service 是被哪個字段觸發(fā)的、觸發(fā)時機是什么等等，那么 Service 的格式如下所示：

由于 Service 可能是異步的，所以這里 Service 都返回一個 Promise，然后將所有的 Service 都注入到 FormRenderer 中，F(xiàn)ormRenderer 根據(jù)表單項配置中聲明的調(diào)用時機去調(diào)用 Service，整個數(shù)據(jù)獲取的鏈路就完成了。

獲取 Service 返回值并在配置項中表達

上文中提到，Service 的返回的數(shù)據(jù)都被存儲在 FormRenderer 內(nèi)部的 extraData 中，一般情況下如果使用 jsx 當然能很容易地取到對應的值，但是在 JSON 中，是沒辦法表達的。但是我們可以借鑒 jsx 的插值表達式和 vue 的插值表達式。

在 jsx 中，如果在一對標簽內(nèi)部寫了一串字符串，對應的會有兩種解析策略，第一種是直接識別為字符串，第二種如果識別到花括號，則將其視為 js 表達式。 同理，在 JSON 配置中也可以使用這種方式去取值。

● 函數(shù)表達式

上例中，使用一對花括號聲明函數(shù)表達式，表面上是借鑒了 jsx 的插值表達式，但是其實兩者有很大的區(qū)別。jsx 的插值表達式是在編譯階段就轉(zhuǎn)化成了 js 表達式。而在 JSON 中的這種自定義的函數(shù)表達式要在運行時轉(zhuǎn)換，上述的函數(shù)表達式只能被轉(zhuǎn)換為函數(shù)執(zhí)行。即：

出于安全問題考慮，表達式還需要被放在一個類似沙箱的環(huán)境中執(zhí)行，避免表達式內(nèi)部修改全局環(huán)境變量。創(chuàng)建簡易沙箱使用 proxy + with + symbol.unscopables 的方式，這里不展開講解了。最終函數(shù)表達式的應用大概是如下形式：

到目前為止，已經(jīng)有了兩個新概念：Service 和 函數(shù)表達式，回到上文中提到的問題，我們已經(jīng)解決了 Select 下拉框來源于接口的問題，那么還剩下如下問題：

· JSON 中只能表達基本的數(shù)據(jù)結構，而沒辦法直接表達邏輯

· 無法在配置中描述 onChange、onSelect 等事件回調(diào)函數(shù)，也不能自定義表單校驗器

· 不能自定義表單校驗器，無法支持復雜的 Tootip 提示，比如帶有 a 標簽的 Tootip

json 中沒辦法表達邏輯的問題，其實已經(jīng)可以通過函數(shù)表達式來解決了。函數(shù)表達式內(nèi)部支持寫任意的 js 表達式，另外，在函數(shù)表達式中也可以支持訪問 form 表單數(shù)據(jù)，有了數(shù)據(jù)支持和邏輯表達能力支持，絕大多數(shù)情況下的已經(jīng)能夠滿足 UI 渲染中的邏輯表達了。

而描述 onChange、onSelect 等事件回調(diào)函數(shù)可以通過配置 Service 來解決。

自定義表達校驗器可以通過函數(shù)表達式的變種來解決，可以向 FormRenderer 中注入 form 校驗器的集合，然后通過 {{ ruleMap.xxx }} 來指定表單項的某一條校驗規(guī)則的校驗器。

Tooltip 提示也是如此。目前結構如下圖所示：

表單數(shù)據(jù)聯(lián)動

表單數(shù)據(jù)聯(lián)動實際上就是當表單中某個表單項值變化時，去重置其他表單項的值，那么要在配置中描述這種聯(lián)動關系有兩種方式：

· 當前字段受哪些字段的影響

· 當前字段的值變化會影響到哪些字段

一般情況下，在代碼中描述這種邏輯時都是采用第二種方式，也就是監(jiān)聽某個字段的值的變化，然后在回調(diào)函數(shù)中去做對應的數(shù)據(jù)聯(lián)動操作。

但是在配置 JSON 時，第二種方式就變得不那么友好了，那會讓字段配置之間產(chǎn)生更多的耦合。更加友好的方式是在某個字段內(nèi)表達本字段受到哪些字段的影響，這樣做的另一個好處是，當開發(fā)者填寫或者修改某一個字段的配置時，可以更加聚焦，不用關心其他字段的配置。

這里用 dependecies 字段來表達當前字段的值受哪些字段的影響。舉個例子，表單中有數(shù)據(jù)源、schema、table 三個字段，數(shù)據(jù)源變化時，schema 的值應該被重置；schema 變化時，table 的值會被重置。那么在 json 中應該這樣描述：

對應的依賴關系圖如下：

這里新的問題產(chǎn)生了，當數(shù)據(jù)源變化時，table 的值是否要被重置？一般情況下是肯定的。那么實際上它們的依賴關系是這樣的：

這里有兩種方式來解決這種隱式的依賴關系：

· 開發(fā)者在配置時顯式得聲明所有的依賴關系

· 渲染器內(nèi)部解析依賴關系時，將這種隱式的依賴關系也解析出來

那么如何選擇使用哪一種方式呢？

如果采用第一種方式，優(yōu)點是渲染器不再需要關心這種隱式的依賴關系了，但是在配置時的心智負擔可能比較大，很容易出現(xiàn)漏配依賴關系的情況。

如果采用第二種方式，優(yōu)點是配置起來心智負擔低，但是也有可能出現(xiàn) table 確實不依賴 sourceId 的情況，也就是間接依賴不生效的情況。

結合實際業(yè)務看，目前的業(yè)務中，所有的字段之間間接依賴其實都是隱式依賴，也就是需要生效的，這里采用第二種方式。前文中也提到了，期望是 FormRenderer 可以盡可能的吸收掉表單內(nèi)部的復雜度。

特殊的表單數(shù)據(jù)聯(lián)動

在實際業(yè)務中還存在著一些比較特殊的表單數(shù)據(jù)聯(lián)動，比如：

· 選擇數(shù)據(jù)源時，除了需要收集數(shù)據(jù)源的 id，還需要收集數(shù)據(jù)源類型

· 選擇數(shù)據(jù)源后，需要將數(shù)據(jù)源的其他信息展示為表單項，比如下圖中的表單

對于這種業(yè)務場景，我們可以理解為某個表單項的值是由其他表單項的值派生出來的，那么就需要去描述這種派生邏輯。當然，這種派生邏輯可以在業(yè)務代碼中描述，只需要在數(shù)據(jù)源變化時，手動的 setFieldValue 就可以了。但是還是上文中提到的期望，F(xiàn)ormRenderer 可以盡可能吸收掉復雜度。

處理這種情況，需要新增一個配置項去描述派生邏輯，這里配置項定為 valueDerived，這個配置項的值應該為一個取值表達式，那么以第一個例子為例，配置應該如下所示：

FormRenderer 內(nèi)部根據(jù)配置的 valueDerived 去自動更新表單中對應字段的值。

表單 UI 聯(lián)動

表單 UI 聯(lián)動可以分為以下兩個部分。

表單項 UI 文案、樣式等根據(jù)數(shù)據(jù)聯(lián)動

表單項的 UI 聯(lián)動在 React 和 JSX 中，都能很輕易、很自然的發(fā)生。但是想要在 JSON 中描述，由于JSON本身不具備表達邏輯的能力，還是要借助函數(shù)表達式。只需要支持對應的配置項可以使用函數(shù)表達式就能完成表單項的聯(lián)動。舉個例子：

那么它們實際渲染時等同于以下偽代碼：

這樣就能做到表單項的文案樣式等根據(jù)數(shù)據(jù)變化自然的聯(lián)動。

表單項的顯示與隱藏

表單項的隱藏也能拆分為以下兩種情況：

· 隱藏但不銷毀，表單項的值仍然會被收集和保留

· 銷毀，不再保留/收集表單項的值

隱藏但不銷毀的情況，antd form 本身就有 hidden 配置支持，那么這里只需要支持 hidden 配置使用函數(shù)表達式就可以了。

對于表單項的銷毀，就需要新增一個字段了，這里命名為 destory，同樣通過支持使用函數(shù)表達式完成聯(lián)動，但是這里需要考慮一些其他情況。比如從銷毀狀態(tài)變成顯示狀態(tài)時，需要去觸發(fā) mount service 等。

思路小結

回顧上文需求分析中所說的需要實現(xiàn)的功能：

· 表單項的基礎信息，比如字段名、label、表單組件、校驗信息等

· 表單項數(shù)據(jù)之間的聯(lián)動

· 表單項 UI 的聯(lián)動（控制顯示/隱藏）

· 表單項的值變化時需要觸發(fā)的副作用（比如調(diào)用接口）

目前在思路上，上述功能都是可以實現(xiàn)的。除了基礎的渲染功能以外，F(xiàn)ormRender 需要額外實現(xiàn)的功能有：

· 內(nèi)置一個 extraData 存儲 Service 返回的數(shù)據(jù)

· 支持根據(jù)配置在正確的時機觸發(fā) Service

· 支持函數(shù)表達式

· 支持根據(jù)配置在內(nèi)部處理數(shù)據(jù)聯(lián)動邏輯

大體實現(xiàn)

整體上，導出一個 FormRenderer 組件，上文中提到的 json config、Service 聲明、自定義的表單校驗器，自定義表單項組件等，都通過 FormRenderer 的 props 傳入。

內(nèi)置 extraData

由于 extraData 內(nèi)部存儲的數(shù)據(jù)變化可能導致視圖更新，那么只能使用 React.Context 或者 state，事實上即使使用 Context 也還是需要聲明 state 來觸發(fā)視圖更新，但是 Conetxt 在傳遞數(shù)據(jù)時有著獨特的優(yōu)勢，這里直接使用 Context 存儲數(shù)據(jù)。

在正確的時機觸發(fā) Service

在 JSON 配置中 Service 相關描述如下所示：

triggerServices 已經(jīng)很清楚直觀的描述了，該字段在什么時機應該調(diào)用哪個 service，在代碼實現(xiàn)上，為了這部分觸發(fā)邏輯與視圖渲染分離，采用發(fā)布訂閱模式。大體流程如下圖所示：

這里流程已經(jīng)走通了，但是可以發(fā)現(xiàn)，renderer 中仍然需要去處理訂閱的邏輯，Service 觸發(fā)邏輯與視圖渲染邏輯分離的不夠徹底，那么可以繼續(xù)優(yōu)化一下，加入一個訂閱器去處理這部分邏輯，優(yōu)化后的邏輯如下圖所示：

支持函數(shù)表達式

上文中提到了，函數(shù)表達式的實現(xiàn)是用 new Function，以及處于安全問題考慮需要將函數(shù)表達式放到模擬沙箱環(huán)境中執(zhí)行，執(zhí)行流程如下所示：

實現(xiàn)代碼如下所示（不包含正則處理）：

比如在 label 配置中使用了函數(shù)表達式：

那么經(jīng)過轉(zhuǎn)換后，就是等同于以下函數(shù)：

具體應用如下：

支持根據(jù)配置在內(nèi)部處理數(shù)據(jù)聯(lián)動邏輯

與上文中 Service 觸發(fā)邏輯一樣，將這部分聯(lián)動的邏輯通過發(fā)布訂閱與視圖渲染邏輯分離。但是相比于 Service 觸發(fā)邏輯，這里多了分析依賴的步驟。比如，有如下 json 配置：

那么生成的依賴關系圖就應該是：

生成上述依賴關系后，剩下的流程與觸發(fā)Service 的流程類似，在這里不多做贅述了。

《數(shù)據(jù)治理行業(yè)實踐白皮書》下載地址：https://fs80.cn/l134d5?

《數(shù)棧V6.0產(chǎn)品白皮書》下載地址：https://fs80.cn/cw0iw1

想了解或咨詢更多有關袋鼠云大數(shù)據(jù)產(chǎn)品、行業(yè)解決方案、客戶案例的朋友，瀏覽袋鼠云官網(wǎng)：https://www.dtstack.com/?src=szbzhan

同時，歡迎對大數(shù)據(jù)開源項目有興趣的同學加入「袋鼠云開源框架釘釘技術 qun」，交流最新開源技術信息，qun 號碼：30537511，項目地址：https://github.com/DTStack