开发动态表单引擎- Schema 设计篇

背景

设计和开发协议驱动的动态表单引擎的第一步就是设计 JSON 协议,也是最重要的一个环节。表单领域的 Schema设计思路 目前主要分为两种:

  • 基于 JSON Schema 扩展

  • 自定义 Schema

JSON Schema 介绍

具体请看文档: 理解 JSON Schema

注意很多人把自定义的 JSON 协议 混淆为 JSON Schema,这是不准确的,JSON Schema 是一套标准,是用于描述和验证 JSON 数据结构的协议。

举个例子,假设我们要定义一个表示人员信息的 JSON 数据结构,包括姓名、年龄。可以使用以下 JSON Schema 来描述这个数据结构:

JSON 复制代码
{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "name": {
      "type": "string"
    },
    "age": {
      "type": "integer",
      "minimum": 0
    }
  },
  "required": ["name", "age"]
}

对应的 JSON 可能数据为:

JSON 复制代码
{
  "name:"Jack",
  "age":18
}

可以使用 Ajv 等框架基于JSON Schema 描述 对 JSON 数据进行校验。

那么问题来了,为什么使用JSON Schema作为表单协议?

  • JSON Schema 是现有的国际标准,可降低一定迁移和学习成本,也方便其他人员理解。

  • JSON Schema 是对数据结构进行描述,表单就是为了提交数据,且对嵌套场景友好。

  • JSON Schema 本身就是校验数据的,可对表单校验提供帮助。

使用 JSON Schema

JSON Schema 只能对表单的数据进行描述,不能描述视图,比如字符串是用input还是textera,以及组件的props等都需要进行配置。

目前业内有两种做法:

  • 使用单独 UISchema对视图配置进行描述

  • 扩展 JSON Schema 添加自定义属性

第一种做法的代表就是 react-jsonschema-form,这种做法的好处就是能保证 json schema 的标准化和纯洁,方便迁移和接入。缺点就是两份配置维护起来比较麻烦。

JSON 复制代码
{
  "schema": {
    "type": "object",
    "properties": {
      "string": {
        "title": "字符串",
        "type": "string"
      }
    }
  },
  "uiSchema": {
    "string": {
      "ui:width": "50%"
    }
  }
}

第二种就是就是在 JSON Schema的原有基础上扩展一些自定义属性,代表是阿里的 Formily。它统一以x-*格式来表示扩展属性。这种做法的好处就是维护 Schema 配置比较方便。

JSON 复制代码
{
  "type": "string",
  "title": "字符串",
  "description": "这是一个字符串",
  "x-component": "Input",
  "x-component-props": {
    "placeholder": "请输入"
  }
}

自定义 Schema

这种方式相比 JSON Schema 更灵活简洁。这种平铺的结构,是以UI组件的角度对表单进行表述的,对搭建友好。

JSON 复制代码
[
  {
    "type": "input",
    "model": "key",
    "label": "输入框",
    "defaultValue": "",
    "required": true,
    "description": "描述",
    "props": {}
  }
]

如果是平铺的情况下还好,但如果是嵌套对象或者数组的场景下,这种 Schema 描述起来就没有 JSON Schema 那么清晰了。

总结

基于 JSON Schema 的协议是以数据 的角度对表单进行描述的;而自定义 Schema 是以 UI 的角度对表单进行描述。

两种协议的本质区别就是描述的角度不同,各有利弊。

如果场景简单的情况,没有历史包袱,其实基于 UI 描述的 Schema 就挺好。

但如果考虑到多层嵌套以及复杂联动等场景,感觉基于 JSON Schema 扩展的方式更好一些,这也是 Formily 所采用的方案,我也会采用此方案进行开发动态表单。

目前 Vue 没有特别完善的表单解决方案,虽然 Formily 很优秀也支持 Vue,但感觉还是有些复杂,所以想自己造个轮子,当然主要还是以学习和探索为目的。后面会继续讨论表单引擎的几大问题:

  • 校验

  • 嵌套

  • 布局

  • 联动

参考

developer.aliyun.com/article/883...

juejin.cn/post/686286...

相关推荐
J***Q2924 小时前
Vue数据可视化
前端·vue.js·信息可视化
JIngJaneIL5 小时前
社区互助|社区交易|基于springboot+vue的社区互助交易系统(源码+数据库+文档)
java·数据库·vue.js·spring boot·论文·毕设·社区互助
ttod_qzstudio6 小时前
深入理解 Vue 3 的 h 函数:构建动态 UI 的利器
前端·vue.js
芳草萋萋鹦鹉洲哦6 小时前
【elemen/js】阻塞UI线程导致的开关卡顿如何优化
开发语言·javascript·ui
_大龄6 小时前
前端解析excel
前端·excel
1***s6326 小时前
Vue图像处理开发
javascript·vue.js·ecmascript
一 乐6 小时前
应急知识学习|基于springboot+vue的应急知识学习系统(源码+数据库+文档)
数据库·vue.js·spring boot
槁***耿6 小时前
JavaScript在Node.js中的事件发射器
开发语言·javascript·node.js
一叶茶6 小时前
移动端平板打开的三种模式。
前端·javascript
前端大卫6 小时前
一文搞懂 Webpack 分包:async、initial 与 all 的区别【附源码】
前端