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

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

針對(duì)這一功能，目前采用的解決方案是，在配置項(xiàng)上加上指定的eventName，當(dāng)數(shù)據(jù)項(xiàng)發(fā)生改變時(shí)，針對(duì)不同的數(shù)據(jù)情況顯示或隱藏表單項(xiàng)，代碼如下：
artifactStrategyChange: (attrValue) => { if (attrValue === ‘latest’) { $this.delete(‘a(chǎn)rtifactRepositoryId’) $this.delete(‘a(chǎn)rtifactName’) $this.delete(‘a(chǎn)liasName’) $this.add(‘a(chǎn)rtifactVersion’) $this.add(‘a(chǎn)rtifactUrl’) $this.add(‘a(chǎn)rtifactPath’) }},
當(dāng)然，這部分代碼還是免不了要在前端實(shí)現(xiàn)，這已經(jīng)比一個(gè)個(gè)的寫完整的表單工作量少了太多。

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。