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

相关推荐
gnip29 分钟前
企业级配置式表单组件封装
前端·javascript·vue.js
一只叫煤球的猫1 小时前
写代码很6,面试秒变菜鸟?不卖课,面试官视角走心探讨
前端·后端·面试
excel2 小时前
Three.js 材质(Material)详解 —— 区别、原理、场景与示例
前端
掘金安东尼3 小时前
抛弃自定义模态框:原生Dialog的实力
前端·javascript·github
hj5914_前端新手6 小时前
javascript基础- 函数中 this 指向、call、apply、bind
前端·javascript
薛定谔的算法6 小时前
低代码编辑器项目设计与实现:以JSON为核心的数据驱动架构
前端·react.js·前端框架
Hilaku7 小时前
都2025年了,我们还有必要为了兼容性,去写那么多polyfill吗?
前端·javascript·css
yangcode7 小时前
iOS 苹果内购 Storekit 2
前端
LuckySusu7 小时前
【js篇】JavaScript 原型修改 vs 重写:深入理解 constructor的指向问题
前端·javascript
LuckySusu7 小时前
【js篇】如何准确获取对象自身的属性?hasOwnProperty深度解析
前端·javascript