isRequired用于配制表單校驗，標(biāo)識該項是否為必填項；

valueProvider是一個非常重要的配置，也相對復(fù)雜，他是一個JSON串，對于下拉框這種需要發(fā)送請求向服務(wù)端獲取下拉框所需要的選項的表單項至關(guān)重要，同時也關(guān)系到表單聯(lián)動的實現(xiàn)，其中的url代表向服務(wù)端發(fā)送請求所所使用的url是什么；

valueField表示獲取到的展示數(shù)據(jù)用哪一項來作為id；

labelField表示哪一項來作為label展示給用戶，multiSelect代表下拉框是否可以多選；

eventName表示當(dāng)這一項的值發(fā)生改變后，會觸發(fā)前端某個寫好的事件做相應(yīng)的處理，eventName的值就是事件名，而事件的定義由前端來實現(xiàn)。

表單聯(lián)動主要有兩種方式：

第一種是當(dāng)用戶修改表單中某一選項時，表單顯示的內(nèi)容有所變化，如圖顯示，當(dāng)用戶選擇不同的介質(zhì)策略時，顯示的表單項也是不同的。

針對這一功能，我們目前采用的解決方案是，當(dāng)表單項改變時，觸發(fā)通過eventName設(shè)置的處理事件，當(dāng)數(shù)據(jù)項發(fā)生改變時，針對不同的數(shù)據(jù)情況顯示或隱藏表單項，這一功能需要前端事先寫好處理事件然后將事件名告知后端，后端將事件名設(shè)置到需要的表單項上去。

第二種是數(shù)據(jù)聯(lián)動，表單中包含代碼庫和branch／tag／commitId兩個輸入項，顯然后者的顯示內(nèi)容取決于用戶選擇了哪個代碼庫，此處就需要前端檢測用戶對代碼庫的選擇，然后將選定后的數(shù)據(jù)作為參數(shù)向后端發(fā)送請求查詢branch／tag／commitId項的列表，為了解決這一問題，要求在配置動態(tài)表單的數(shù)據(jù)獲取url時將需要的參數(shù)以冒號加對應(yīng)表單項的字段名形式配置，示例：／repo／commit？repoId＝：repoId。前端會將表單解析為一個完整的數(shù)據(jù)對象，其中每一個屬性代表一個表單項，屬性名采用attrId，解析后的數(shù)據(jù)對象如圖所示，動態(tài)表單會將數(shù)據(jù)對象完整的傳遞給每一個表單項，當(dāng)repoId發(fā)生改變時，branchId的對應(yīng)的表單項會監(jiān)聽到數(shù)據(jù)對象的變化，并對其屬性進(jìn)行遍歷，如果有其url屬性所需的屬性時會重寫branchId的url屬性并且向服務(wù)端發(fā)送新的請求獲取數(shù)據(jù)源。

前面說過isRequired屬性用于設(shè)置是否為必填，前端也是僅在表單項上加上了required（VUE框架下）的配置而已，并沒有做更多的復(fù)雜校驗。

二、問題和新需求

隨著DevOps市場需求升級，我們收到了一個足以引起DevOps動態(tài)表單徹頭徹尾改變的需求——工作項動態(tài)表單化配置，項目管理是DevOps的重要功能之一，6．1GA版本前的任務(wù)項管理所有的屬性表單都是固定的，不支持用戶做任何自定義修改，但是，這無法滿足市場的需求，不同的應(yīng)用場景對任務(wù)管理的要求是不一樣的，比如原有的工作項僅支持故事、任務(wù)、Bug三種類型的工作項管理，每種類型的屬性也是固定的，這樣的用戶體驗較差，某些場景下用戶可能需要更多類型的工作項，用戶更喜歡將“故事”叫做“需求”，等等這一系列的需求，經(jīng)過討論分析，我們決定使用動態(tài)表單來實現(xiàn)這一功能。而原有的動態(tài)表單設(shè)置，雖然能滿足CICD的任務(wù)配置，但它如果用于工作項管理配置，其缺點也是不可忽視的。因此我們決定重新制作一款更強(qiáng)大更靈活的動態(tài)表單。

新的動態(tài)表單需要具備如下幾個主要基本功能：

支持可視化頁面配置表單

布局自定義

表單項類型自定義

表單校驗自定義

表單聯(lián)動自定義