【中後臺應用】從表單抽象到表單中臺

時間 2019-11-05

原文原文鏈接

從表單抽象到表單中臺

做者:jinchtml

相信前端開發的同窗，對錶單其實並不陌生，並且時至今日，表單應用的編寫由於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 ); 複製代碼

定義表單

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

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

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

人機交互行爲
轉換爲數據

人機交互行爲

爲何不是表單組件（輸入框、上傳文件、選擇框等等），而是人機交互行爲？由於在表單應用的開發中，會有更多地用戶對數據進行輸入場景，而基本的表單組件只是其中的一類行爲而已，若是哪天咱們的表單裏面，須要用戶在一個畫板上畫圈圈呢？異步

轉換爲數據

咱們最終與服務器進行傳遞的東西，不過是一份數據而已，而表單很重要的一個做用，就是將人機交互的行爲轉換爲計算機可以存儲的數據，而後與接收方進行通訊。函數式編程

因此，表單是這樣的：

高級模式-動態表單

聰明的開發者固然不想天天都重複地寫着相似的代碼，動態表單也是所以而生的吧。

動態表單，說白了就是隻須要經過一份配置，就能生產一個表單應用。它可以極大地提高咱們的效率，組件的複用率等等。開發者從寫代碼到了寫配置。

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

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

爲了解決它的問題，因而筆者基於動態表單，設計了一個表單中臺。

表單中臺的設計

表單中臺是經過對錶單進行了抽象，而後單獨針對網站應用上的全部表單而設計的。

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

表單配置的可視化生產

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

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

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

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

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

表單中臺

表單中臺是一個能夠徹底由前端驅動的產品，由於表單裏面跟數據存儲查詢是能夠相對對立的部分，無論數據跟哪一個服務器進行通訊，都是不須要關心的，標準應該有前端進行制定。這樣，它就是一個去中心化的產品，同時也具有成爲一箇中臺的可能。由於它是一箇中臺，因此它也是可以支撐和驅動各類N箇中後臺和業務發展的。

架構設計

通訊層與服務器

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

例如配置查詢的接口：

參數	類型	是否必須	說明
formId	Long	否	表單ID
type	Long	是	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
    }
  }
複製代碼