开发动态表单引擎- 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...

相关推荐
meilindehuzi_a15 分钟前
从零理解并实现 RAG:用 LangChain.js 构建语义检索问答系统
开发语言·javascript·langchain
世界哪有真情1 小时前
拿人类意识卡 AI?等于用 bug 验收正式产品
前端·人工智能·后端
鱼樱前端2 小时前
别再自己拼凑了!这款 Vue 3.5+ 严肃产品级组件库,把 AI 对话、工作流和复杂数据全包了!
javascript·vue.js·github
Listen·Rain2 小时前
Vue3:setup详解
前端·javascript·vue.js
Patrick_Wilson3 小时前
修好 bug 只是开始:一次由监控需求反向重构日志结构的复盘
前端·监控·数据可视化
kyriewen3 小时前
面试官让我优化一个卡死的表格,我打开 Claude 五秒重写,他放下咖啡问我要不要来当组长
前端·javascript·面试
小粉粉hhh4 小时前
React(二)——dom、组件间通信、useEffect
前端·javascript·react.js
Csvn4 小时前
🤖 AI 生成前端代码的 5 个典型翻车现场及修复指南
前端
IT_陈寒5 小时前
SpringBoot自动装配坑了我一天,原来问题出在这
前端·人工智能·后端
索西引擎6 小时前
【React】key 属性:协调算法中的元素标识机制与最佳实践
前端·javascript·react.js