动态表单工作量给后端
動(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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 机器学习PAL数据可视化
- 下一篇: 汉字手写训练和识别