编者寄语：本期为大家带来基于 Formily 的拖拽式表单设计器玩法，摸索可视化时代表单设计器的可能。

背景

在控制台类 web 利用中，表单是最常见的交互模式。用户在表单中填写信息，点击提交就能实现对数据创立或者批改操作。

最开始，前端开发人员依据业务模型和具体需要，通过逐个编写或者申明实现表单中的各个字段，测试通过之后公布上线。慢慢地，开发人员开始把一些罕用的办法形象成表单库复用，晋升开发效率。随着业务复杂度的减少和需要的一直演进，对表单的展现模式和灵便水平要求也在一直进步，现有的表单库只能解决局部问题，开发者仍需破费大量的精力在更新表单字段或者开发新表单上。

那有没有一种形式，既能让开发人员疾速构建表单，同时在前期又很少或者基本不须要开发人员染指来更新表单呢？

此时，表单设计器应运而生。表单设计器提供了可视化界面，让非专业开发人员也能通过拖拽的形式，所见即所得的构建业务所需表单。

表单设计器款式

目前很多开源的表单设计器实现，在 UI 上都大同小异，设计器的构造相似设计软件的布局。表单设计器个别为左中右三栏布局:

• 左侧是控件列表，列出了设计器反对的表单控件。
• 两头局部是画布（canvas），左侧的控件可间接拖拽到画布中，并反对控件调整程序、复制等操作。
• 右侧是表单字段的配置区域，在画布中选中一个字段，右侧将展现此字段的所有属性，用户可在此处配置字段题目、形容、校验规定等。

原理解析

表单设计器的输入是一份形容表单字段的 JSON Schema，表单设计实现后 JSON Schema 将间接存储到后端。表单公布后，前端再依据 JSON Schema 渲染表单。表单中所有字段的信息都是存储在 Schema 中，所以每次对表单的更新都是批改 Schema 中的内容，无需传统的编译过程。借助表单设计器，岂但将开发人员从应答业务变更的频繁改变中解放出来，同时大大提高了非专业开发人的生产力，缩小了沟通老本。

JSON Schema 是表单设计器和表单渲染组件之间沟通的语言。要了解表单设计器的外围，首先要了解 Schema。在理论的我的项目中，JSON Schema 个别比较复杂，此处不做开展。本文的主题是表单设计器的实现原理，次要关怀的是如何提供一个可视化界面，让用户可能疾速生成 Schema，Schema 的具体格局将在后续文章中介绍，这里先提供一个简化版本的定义：

    interface Schema {fields: Record<FieldKey, FieldSchema>;}
    ​
    interface FieldSchema {
        title: string;
        type: 'string' | 'object' | 'array' | 'number' | 'boolean';
        component: string;
        componentProps: {[name: string]: any;
        };
    }

家喻户晓，表单由多个 input 控件组成，input 控件蕴含多种形式，如：文本、数字、单选和多选等。Schema 中除了形容字段对应的是哪种类型的 input 外，还须要形容控件的行为，例如是否限度输出长度、是否必填等。有了这些形容后，表单渲染组件能力依据 Schema 渲染出合乎预期的表单。
在下面的类型定义中：

• component 示意该字段用什么 input 组件渲染。
• componentProps 示意传给组件的 props，用于管制组件的行为。
• type 示意组件承受和冀望返回的数据类型。
• FieldKey 是字段在表单中的惟一标识，用户侧不透出。
• title 示意表单中字段对应的 label，它的值用户可读。

表单设计器的工作就是从零开始，或者将已有的 JSON Schema 作为输出，对 Schema 中的字段做增加、删除和更新操作，最初输入 Schema。如果咱们把表单设计器看成一个整体，那它的性能能够用下图示意：

进一步讲，咱们能够将上图拆分到控件级别，以一个字段的配置作为输出，通过更新后从新输入这个字段的配置。

整体来看，表单就是对每个控件的操作进行组合，组合的后果就是残缺的 JSON Schema。

为了可能实现对表单字段的批改，咱们在表单设计器中提供了字段配置区域，用户在配置区域中，能够通过可视化形式定义字段属性，而无需关怀 Schema 的具体格局。表单设计器负责将配置值转化成 Schema，同时也负责将 Schema 转化成配置值，用来回显配置后的页面表单。

阐明：
配置区域其实也是一个表单，每种类型的控件也都有本人特定的配置表单。
想要实现上述性能，每种控件都须要实现两个办法：toConfig 和 toSchema。这里用一个公式来示意这两种办法和 Schema 的关系，其中 configValue 用来给配置表单做回显。

    FieldSchema => toConfig => configValue => toSchema => FieldSchema

厘清了上述思路之后，咱们再回到表单设计器的 UI 出现上来。

左侧是设计器反对的控件列表，依据下面的剖析，每个控件都须要提供控件名称、配置表单、toConfig 和 toSchema 这四个接口的实现。两头的 canvas 负责展现 Schema 中的控件，同时须要解决用户的点击和拖拽事件。当用户点击 canvas 中的某个字段时，右侧的配置区域须要找到对应的配置表单并渲染进去。

总结

以上是表单设计器最外围的架构实现，还有一些实现上须要思考的细节，如表单 Schema 定义解析等将在后续的文章中逐渐论述，请大家继续关注。

全象云低代码平台的表单设计器就是基于 Formily 实现的。Formily 的灵便扩大能力和为业务而生的个性让咱们钦佩，感激 Formily 团队的奉献，心愿咱们前面也能为 Formily 奉献代码。

作者

段国伟、汪曦