前言
对于业务逻辑足够复杂的企业级管理型软件，有限的空间维护更多的业务信息、查看更多的业务信息一直是企业级终端用户的诉求。
而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)
这样就可以直接构建出一个数据双向绑定的表单, 是不是很方便？这也有利于中台的建设。
眼尖的同学就会注意到componentType这个特殊的字段，它是什么呢？
componentType 从语义上看就是组件类型，但是它不同于一般的组件，它应该有它的规矩
这也和Table的单元格编辑一样共同引出了一个概念——数据单元。
DataCell 数据单元
一个阳光明媚的清晨，Tom面对着电脑屏幕说，这个表格我目前只想看，但不代表我等会不编辑，我等会编辑的时候能不能像Excel一样编辑？
一个慵懒的午后，Lucy说，这个表单我目前只想看，但我待会要编辑，我阅读的时候别显示那么多框框。
城市灯光亮起、下班回家的路上，John突然有了疑问，表单和表格都是做数据的展现和维护，为什么表格和表单不做成都是可以即有读状态又有写状态呢？读写状态能不能分离开呢？
他意识到对于对象的信息，并不是一上来就要去更改，更多的时候应该是先去读这个对象，读写分离还可以保护数据不被误操作。他立刻意识到了这是一种或一系列组件，一种可以同时使用在Table和Form中的组件。
我们是时候需要一种机制让读写分离开了
数据单元是什么？
数据单元是数据展示或维护的最小单元组件，它可以支持只读模式和写模式。
从业务角度看，数据单元独立负责着一块业务或者一个业务属性，负责着业务信息的读和写
而对于一般表单的常规情况就是默认是写状态的，
类似这样(https://github.com/settings/profile)：
而对于像名片或简历展示一样的需求，类似这样（钉钉的名片）：
遇到了读的视图我们不可能在业务层再写一套专门读的视图，如Description，那样就太麻烦了。
所以我们需要这种组件即支持读，也支持写。通俗的讲就是把以上两张图的name和昵称合成一个组件。
并且需要同时支持在表单和表格中使用
这种组件就是数据单元的由来。
欢迎
我们的专注点将主要持续在数据密集型业务场景Table和Form这两种组件上，Gantd 大家不妨尝试下，说不定可以解决你的一些问题。
