動態表單工作量給后端
讓前端遠離互相傷害
一個IT公司的日常就是程序員、產品經理、UI等同事們的互相殘殺：
應用，不少前端就備受煎熬，除了修改需求的魔咒外，還有后端的重構和調整接口詛咒，即便需求沒改，后端接口或數據結構的調整前端也要巴巴的陪著改，甚至還要為此做大型重構。但是前端重構就真的只是前端重構，和后端一毛錢關系都沒有，工作量還是前端的，bug永遠是先提給前端，簡言之就是，修改需求前端要改，修改接口前端要改，改bug前端要先看（此處省略血淚史一萬行）難道前端就不能反殺一波，擺脫困境了嗎？當然可以，答案就是動態表單，自從有了它，可甩掉不少工作量。
前端開發最煩人的事之一就是寫一堆大同小異的表單，使用的控件類型有很強的規律性，同類型控件調用的后端接口類型也非常相似，每個表單用到的具體接口、控件種類和控件數量又不盡相同，就算封裝控件復用也是杯水車薪，無法提升工作效率。前端為了應對后端接口不斷調整修改，在框架層上封裝了一套接口調用機制，很大程度上降低了后端接口url調整給前端的影響，不論怎么改只要接口名稱不變，前端統統可以一鍵搞定，而且還同步建立了數據管理機制，提升前端性能。
這次，面對這些討厭而又常用的表單，前端的態度一樣是不能忍的。既然不能躲避，那就想辦法解決。因此開發了一套動態表單，從表單內容到數據提交統統由后端配置，前端只需要讀取解析表單配置渲染相應內容即可，用戶完成表單后提交數據發送的請求也是由后端配置，前端做的只是按照要求發送數據即可。這樣，前端在表單這一塊就再也不用被產品經理和后端影響，不論需求怎么改，表單怎么加，都不需要前端在做附加工作了，留下產品經理和后端研發互相傷害，前端幫著改改bug。
動態表單對很多前端開發人員來說并不陌生，前后端約定好表單配置數據模型，前端只需要實現動態表單解析功能即可。一套完整的產品怎么可能只有簡簡單單的表單配置能，聯動表單、表單校驗等對前端來說依舊是個比較棘手的問題。以DevOps動態表單為例來說說表單聯動問題如何解決。
表單聯動主要有兩種形式，一是表單項的數據聯動，再來就是表項顯示聯動。
先來說說表單項數據聯動，舉個例子：表單中包含代碼庫和branch/tag/commitId兩個輸入項，顯然后者的顯示內容取決于用戶選擇了哪個代碼庫，此處就需要前端檢測用戶對代碼庫的選擇，然后將選定后的數據作為參數向后端發送請求查詢branch/tag/commitId項的列表。

這樣的功能看著并不復雜，只需要監聽代碼庫的選擇實事件然后在事件處理中調用branch/tag/commitId項的查詢請求即可。但是，別忘了你現在在寫動態表單，一切都是配置好的模型，不能針對單獨的某字段名寫if else做特殊處理（否則還叫什么動態表單），代碼是固定的，不能寫任何個性化的代碼來處理事件，而且這只是一個簡簡單單的兩項聯動，真正的項目開發中，多項聯動比比皆是。為了解決這一問題，前端在數據模型的設計上做了一定的思考，要求后端在配置動態表單的數據獲取url時將需要的參數以冒號加對應表單項的字段名形式配置，示例：api/repo/commit?repoId=:repoId。此后，前端在解析整個表單的時候會給每一個表單項傳遞完整的表單數據對象，當表單數據中的某項發生改變時，需要向后端發送請求的一些表單項會監聽整個表單數據的變化，將與改變的表單項字段名相匹配的url進行重寫，替換上對應的值，然后用發生改變的url向后端發送請求獲取新的數據。配置示例如下：
[{ attrId: ‘repoId’, defaultValue: null}, { attrId: ‘branchId’, defaultValue: null, url: ‘api/repo/commit?repoId=:repoId’}]
再來就是動態表單聯動顯示問題，如下圖顯示，當用戶選擇不同的介質策略時，顯示的表單項也是不同的：

針對這一功能，目前采用的解決方案是，在配置項上加上指定的eventName，當數據項發生改變時，針對不同的數據情況顯示或隱藏表單項，代碼如下：
artifactStrategyChange: (attrValue) => { if (attrValue === ‘latest’) { $this.delete(‘artifactRepositoryId’) $this.delete(‘artifactName’) $this.delete(‘aliasName’) $this.add(‘artifactVersion’) $this.add(‘artifactUrl’) $this.add(‘artifactPath’) }},
當然，這部分代碼還是免不了要在前端實現，這已經比一個個的寫完整的表單工作量少了太多。

DevOps產品的CICD部分全部采用動態表單體系實現，在功能擴展上是極為迅速的，只要后端完成開發，基本整個功能擴展就接近了尾聲。經過的實踐，這套表單體系仍然有許多可優化之處，也在不斷的進行優化和調整，力求將它應用到更多產品中，盡可能的減少開發人員的工作量，提升產品質量，縮短產品交付時間。
動態表單雖好但是也要充分考慮使用場景和開發代價，不要為了過分抽象代碼反而本末倒置，過度設計反而提高了研發成本。

總結

以上是生活随笔為你收集整理的动态表单工作量给后端的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。