前言

对于业务逻辑足够复杂的企业级管理型软件，有限的空间维护更多的业务信息、查看更多的业务信息一直是企业级终端用户的诉求。

而AntD所提供的解决方案面向的是受众很广的企业级软件，不是很侧重于对于大数据量数据密集型的业务场景，所以GantD诞生了。

Table和Form是企业级管理型软件最重要的两种组件，GantD对这两种组件做了归纳、业务收敛，客官不妨里面请，来看看GantD中Table和Form的爱恨情仇：

Table 表格

表格对应的数据结构要么是list, 要么是tree，对于数据的维护，有可能是维护一行（一个业务对象）或者维护一个单元格（一个业务对象的属性）。

对于一般表格常规的情况就是默认是只读的，而想要去编辑，交互行为要么是弹窗，要么是跳转，要么是单元格编辑。

先讲单元格编辑

在很久以前，企业的一些业务没有对应匹配的管理软件的时候，人们用的是Excel去维护数据。如果你了解这些，你就会了解这些企业对于业务软件中的表格的期望方向，以及对于表格的单元格编辑是多么的依赖。

而这种单元格编辑的习惯从业务场景交互设计的角度看其实也是一种比较好的交互行为，便捷直观，尤其是你在维护海量属性和海量数据的时候，可以少很多步骤。(🤨 同样也带来了不小的难度)

而对于表格中的每一列格子，都有可能代表的是一个小业务，比如 John's address、Lili's tags、Tom's tasks

而对于每种小业务所涉及的组件，散落在地、交互行为不成体系将会引起不小的麻烦，对于每一个单元格其实应该有一种组件去维护这个单元格所代表的的业务，这种组件我们称之为——数据单元DataCell(在下面会讲)

对于弹窗形式的编辑，我们一般会用到Form,

对于跳转形式的编辑，一般会跳转到一个详情页，详情页一般情况主体也是From。

编写一个复杂Form表单的呈现以及数据维护逻辑将花费不少的精力和时间，最懊恼的是每个人编写的form表单视图和交互逻辑或许还不统一，其他人很难去阅读一个业务信息零散的、没有语义化描述的Form表单。

这就引出了一个概念，SchemaFrom

SchemaFrom 数据驱动表单

数据驱动表单SchemaFrom是以一段集中的业务描述数据Schema 输入到组件中而直接构建生成的一种表单。

这很好理解，类似这样：

import React,{useState} from 'react'
import { SchemaForm } from 'gantd'
const schema = {
    type: "object",
    title: "普通表单",
    propertyType: {
        name: {
            title: "姓名",
            type: "string",
        },
        age: {
            title: "年龄",
            type: "number",
            componentType: "InputNumber"
        }
    }
}
const [data, setData] = useState({
    name: 'John',
    age: 26
})
function BasicUse() {
    return <SchemaForm schema={schema} data={data}/>
}
ReactDOM.render(<BasicUse/>,mountNode)