從表單抽象到表單中臺

相信前端開發的同學，對表單其實并不陌生，而且時至今日，表單應用的編寫因為React、Vue等框架的出現，也變得更加地便捷了。在前端工作中，有著很多中后臺應用-表單的開發工作量，筆者自己深陷其中，所以為了讓頭發別掉得太快，重新去理解了表單這個東西，從而重新去思考和設計表單的開發模式，提升效率。

理解表單

其實大家都知道表單是什么，但大多數人對它應該沒有一個明確地認識，至少我之前是沒有的。

基礎表單

<!-- https://developer.mozilla.org/zh-CN/docs/Learn/HTML/Forms/Your_first_HTML_form --> <form action="/my-handling-form-page" method="post"><div><label for="name">Name:</label><input type="text" id="name" /></div><div><label for="mail">E-mail:</label><input type="email" id="mail" /></div><div><label for="msg">Message:</label><textarea id="msg"></textarea></div><div class="button"><button type="submit">Send your message</button></div> </form>

這段代碼完成了一個最為基礎的表單，我們來分析下，它都有什么？

• 提交地址、提交方法
• 提示信息
• 輸入框
• 提交按鈕
  然后今時今日，這樣簡單的表單其實并不再能滿足越發復雜的應用需求了。

更豐富的表單

在有了JQ、React、Vue等等之后，網絡和社區上有了更為豐富的表單組件，比如日期選擇、時間選擇器、圖片裁剪上傳等等。

//https://codepen.io/pen/?&editable=true&editors=001 const { TimePicker } = antd;function onChange(time, timeString) {console.log(time, timeString); }ReactDOM.render(<TimePicker onChange={onChange} defaultOpenValue={moment('00:00:00', 'HH:mm:ss')} />,mountNode );

定義表單

可不管怎么變化，提交地址和提交方法、提示信息、用戶輸入、提交按鈕，這些都是不可或缺的，于是我嘗試用簡練的語言來抽象一下表單是個什么東西：

表單是一個將人機交互行為轉換為數據后提交給服務器的可視化前端應用。

想要理解表單，這兩個詞就尤為關鍵：

• 人機交互行為
• 轉換為數據

人機交互行為

為什么不是表單組件（輸入框、上傳文件、選擇框等等），而是人機交互行為？因為在表單應用的開發中，會有更多地用戶對數據進行輸入場景，而基本的表單組件只是其中的一類行為而已，如果哪天我們的表單里面，需要用戶在一個畫板上畫圈圈呢？

轉換為數據

我們最終與服務器進行傳遞的東西，不過是一份數據而已，而表單很重要的一個作用，就是將人機交互的行為轉換為計算機能夠存儲的數據，然后與接收方進行通信。

所以，表單是這樣的：

高級模式-動態表單

聰明的開發者當然不想每天都重復地寫著類似的代碼，動態表單也是因此而生的吧。

動態表單，說白了就是只需要通過一份配置，就能生產一個表單應用。它能夠極大地提升我們的效率，組件的復用率等等。開發者從寫代碼到了寫配置。

就算沒有對表單進行明確的理解，動態表單的組件、框架或者庫類，其實都已經存在著很長的一段時間了。但它卻還是存在著一些問題：

• 有學習配置的成本
• 有開發和維護配置的成本

為了解決它的問題，于是筆者基于動態表單，設計了一個表單中臺。

表單中臺的設計

表單中臺是通過對表單進行了抽象，然后單獨針對網站應用上的所有表單而設計的。

它是對一個網站應用上面的所有表單，從前端開發者對表單相關的開發維護到用戶提交數據到服務端，這樣一個完整鏈路的抽象封裝。

表單配置的可視化生產

表單的配置化其實就是將表單開發的邏輯，轉化成為了一種結構，在前端看來，它是個JSON或者是個對象。手動編寫表單配置是可以被可視化的工具所替代的，這樣，表單的開發和維護就變得更加清晰、簡便了，效率也會得到提升。

一份配置對應著一個表單的時候，但我們在一個網站應用（業務）上有多種場景需要多個表單，這時候就會有多份配置，多份配置會就需要對齊進行管理，甚至需要動態化異步加載配置。我把配置相關的事情，也一并列入表單中臺的設計之中，讓鏈路更加地完整。

說到這里，有些人可能會聯想到一些問卷調查的網站、應用。本質上，它們是一樣的，但問卷調查應用與大家復雜地表單開發工作還是會有很大的不一樣，所以當有表單需求來了的時候，你不會告訴你的業務方說，"你去建立個問卷調查就好啦”。而它與問卷調查系統不一樣的地方就是一個商業系統與中臺系統的區別。所謂的中臺，就是用來驅動和支撐商業系統的。

而實現可視化的手段，就是通過表單來生產配置，然后渲染表單。

可視化生產表單配置的頁面：

表單中臺

表單中臺是一個可以完全由前端驅動的產品，因為表單里面跟數據存儲查詢是可以相對對立的部分，不管數據跟哪個服務器進行通信，都是不需要關心的，標準應該有前端進行制定。這樣，它就是一個去中心化的產品，同時也具備成為一個中臺的可能。因為它是一個中臺，所以它也是能夠支撐和驅動各種N個中后臺和業務發展的。

架構設計

通信層與服務器

通信層磨平了與服務器進行通信的過程，這其中包括了配置的增刪改查，表單數據的讀寫。接口標準由前端進行了定義。

例如配置查詢的接口：

參數類型是否必須說明formIdLong否表單IDtypeLong是0表示根據userId獲取用戶的配置列表，1表示根據formId獲取某個具體配置

核心層

通過之前對表單的抽象，就可以抽象出一些表單相關的JS類，這個些類本質上其實都是一些數據相關的操作，包括但不限于：

• 表單數據驗證
• 表單數據讀寫
• 表單元素的基本屬性

/*** 定義一些標準的表單屬性* - defaultValue* - key* - dataSource* - disabled* - size* - title/labelText* * 方法:* - onChange* - setValue* - verify* @param {Object} config */initFormProps(config){let onChange = (value) => {this.setValue(value)this.formChange(this.key,value)}let getValue = () => {return this._value}return {onChange,getValue,size: this.config.size,dataSource: this.dataSource || [],disabled: this.disabled,defaultValue: this.defaultValue,value: this._value,key: this.key,block: this.config.block === "true" || this.config.block === "true",title: this.title || this.labelText,labelText: this.labelText || this.title,_type: this.type}}

有了這些，就可以在渲染層，進行多框架的渲染對接了。

業務層

在輸出的時候，同時輸出了渲染組件和配置生產組件，配置的生產組件可以不進行上線，只要對接業務接口即可；渲染組件自動拉取對應場景的表單配置進行渲染。

所以，只要一次的接入，后續的表單開發工作，就是三步：

1.（未有滿足的表單組件時）開發自定義的表單組件
2. 在配置生產組件創建表單
3. 在對應場景接入渲染組件

總結

開發者的開發歷程通常會有四個階段：寫代碼、寫配置、可視化生產、中臺。特別是在中后臺的應用場景中，這樣路徑似乎都是有效的。

本文只是說到了表單的中臺，其實，這個思路是可以被復制的，

從表單頁面的可視化，到表格頁面的可視化，再到中后臺站點的可視化，路徑與架構設計都會大致相同。因此，為了解放生產力，還有很長的路要走。

---

關注我們的公眾號FE One，會不定期分享JS函數式編程、深入Reaction、Rxjs、工程化、WebGL、中后臺構建等前端知識

總結

以上是生活随笔為你收集整理的abap mm后台表_【中后台应用】从表单抽象到表单中台的全部內容，希望文章能夠幫你解決所遇到的問題。

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