【中后台应用】从表单抽象到表单中台

时间 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
    }
  }
复制代码

有了这些，就能够在渲染层，进行多框架的渲染对接了。

业务层

在输出的时候，同时输出了渲染组件和配置生产组件，配置的生产组件能够不进行上线，只要对接业务接口便可；渲染组件自动拉取对应场景的表单配置进行渲染。

因此，只要一次的接入，后续的表单开发工做，就是三步：

1.（未有知足的表单组件时）开发自定义的表单组件 2. 在配置生产组件建立表单 3. 在对应场景接入渲染组件

总结

开发者的开发历程一般会有四个阶段：写代码、写配置、可视化生产、中台。特别是在中后台的应用场景中，这样路径彷佛都是有效的。

本文只是说到了表单的中台，其实，这个思路是能够被复制的，

从表单页面的可视化，到表格页面的可视化，再到中后台站点的可视化，路径与架构设计都会大体相同。所以，为了解放生产力，还有很长的路要走。

专栏其余文章

FE One

关注咱们的公众号FE One，会不按期分享JS函数式编程、深刻Reaction、Rxjs、工程化、WebGL、中后台构建等前端知识