docs: add introduction and support FormTab and support FieldState. un…

…mountRemoveValue (#752)

1. Support FormTab
2. Support FieldState.unmountRemoveValue
3. add introduction document

docs/zh-cn/SUMMARY.md

@@ -1,3 +1,7 @@
+
+- 首页
+  - [Formily是什么](./introduction/formily.md)
+  - [竞品对比](./introduction/comparison.md)
 - Schema Form
   - [介绍](./schema-develop/introduction.md)
   - [快速开始](./schema-develop/quick-start.md)

docs/zh-cn/introduction/comparison.md

@@ -0,0 +1 @@
+# 竞品对比

docs/zh-cn/introduction/formily.md

@@ -0,0 +1,153 @@
+# Formily是什么？
+
+
+
+Formily是一个由阿里巴巴集团多BU共建的面向中后台复杂场景的表单解决方案，它也是一个表单框架。
+
+它的前身是供应链平台在2019年初对外开源的UForm解决方案，UForm的前身又是在供应链平台内部自研的某个表单框架。
+
+总体来看，Formily是一个经过了漫长时间所磨炼，沉淀出来的表单解决方案。
+
+同时，我们在集团内部，也有着最复杂的表单场景一直持续在挑战着Formily的极限。
+
+所以，Formily发展到现在，完全是受业务而推进的解决方案，**这不是一个简单的前端轮子！**
+
+这是一个真正意义上，为业务而生的表单解决方案！只要阿里巴巴还有中后台表单场景，Formily就会一直持续维护下去。
+
+
+
+## 面临什么问题
+
+在阿里巴巴集团正式开始打响中后台战役之后，阿里内部各种中后台系统如雨后春笋般猛烈发展，面向B端的业务场景越来越大，也越来越厚重，对于阿里前端工程师而言，即是压力也是机遇，压力是，我们要开发的页面会更多，我们要解决的问题也会更多，如何给商家赋能？又如何给内部用户提效？机遇则是，我们迎来了新的前端蓝海，所以，阿里的Ant Design到Fusion Next再到ICE这一系列的解决方案油然而生。
+
+
+
+但是，我们却始终面临一个心头之痛，表单，在中后台场景下，80%以上的页面，都是由表单组成，每个表单又是由各种形态的表单输入项所组成，当我们有了Ant Design/Fusion Next之后，我们可以轻松做到不需要关心表单输入项内部的复杂交互逻辑了，只需要关注如何组装表单页面即可，这就是组件化所带来的强大赋能。
+
+可是，表单除了表单输入项，其实还有各种数据关联，逻辑联动，校验联动，这些可是实实在在的业务层，如何在这一层里更进一步提效？
+
+同时，因为我们使用的是React技术栈，那我们又该如何解决表单项数量无限增加的交互操作性能问题？
+
+还有，我们的表单能不能通过简单配置即可快速生产表单，即便非技术人员也能快速高效的开发出复杂表单页面？
+
+
+
+**总而言之，怎么更好的管理表单逻辑，怎么保证表单性能，怎么让非技术人员高效开发表单页面这就是我们一直所面临的问题。**
+
+
+
+## Formily
+
+Formily解决方案的本质是构造了一个Observable Form Graph，在这个Form Graph中，我们抽象了整个表单领域模型，同时这个模型又是一个无限循环状态机。
+
+![](https://img.alicdn.com/tfs/TB1cdP2fUT1gK0jSZFrXXcNCXXa-1112-718.png)
+
+这个状态机主要有3个特点：
+
+- 无限循环
+- 分布式管理状态
+- UI无关
+
+在这样一个状态机下，我们就能很简单的来描述字段间的联动关系。我们甚至可以用一句极简表达式来描述：
+
+```
+setFieldState(
+  Subscribe(
+    FormLifeCycle,
+    Selector(Path)
+  ),
+  TargetState
+)
+```
+
+这句表达式描述了
+
+- 任何联动，都需要一个路径来描述具体字段
+- 通过一个选择器来选择字段，同时任何联动都是从表单生命周期而发起
+- 联动的最终操作是操作具体字段的状态，可以是值，可以是它的显示隐藏，也可以是具体组件属性等等。
+
+所以，Formily借助这样一个内核，我们轻松的实现了：
+
+- 在复杂联动场景下更加清晰简单的描述联动的方式
+- 在超多表单项场景下可以获得更好的表单操作性能
+- 在跨终端场景下实现通用表单解决方案
+
+
+
+## 核心特性
+
+在上面有讲到，Formily的状态机模型，当然，Formily不止这些，我们在上层又抽象了几层
+
+- UI桥接层(React/Vue/Angualr/小程序....)，这一层主要是对接各种组件化框架，对不同体系的用户提供更便捷的表单管理方案
+
+- Schema动态渲染层(React/Vue/Angular/小程序...)，这一层主要提供了针对Schema场景下的各种上层能力，比如典型的协议化联动，协议化布局能力
+
+- Schema编辑器层，这一层主要提供了可视化配置Schema能力，方便非技术人员快速配置表单
+
+- 研发工具层，这一层主要提供了针对Formily的开发者调试能力
+
+
+
+## 整体架构
+
+![](https://img.alicdn.com/tfs/TB1BvlRu4D1gK0jSZFsXXbldVXa-1882-1144.png)
+
+从以上架构中，我们可以看到
+
+整个Formily是由一个UI无关的内核所驱动的，这样的好处就是，我们的表单方案，是可以轻松做到跨终端的，同时，在上层，我们拥有一份标准的表单协议，可以做表单动态渲染，所以，我们可以想象一下，**一份JSON Schema驱动多端的表单页面动态渲染** 这样的目标，是可以轻松实现的，这样对于整个前端表单研发领域，是一个突破性的解决方案。
+
+
+
+## 数据公示
+
+Github Stars: ![](https://img.shields.io/github/stars/alibaba/formily)
+
+Github Issues: ![](https://img.shields.io/github/issues/alibaba/formily)
+
+Github Forks: ![](https://img.shields.io/github/forks/alibaba/formily)
+
+Github License: ![](https://img.shields.io/github/license/alibaba/formily)
+
+Github Contributors: ![](https://img.shields.io/github/contributors/alibaba/formily)
+
+NPM Downloads(UForm)：![](https://img.shields.io/npm/dy/@uform/core)
+
+NPM Downloads(Formily)：![](https://img.shields.io/npm/dy/@formily/core)
+
+阿里集团覆盖：
+
+- 供应链平台
+- 淘系技术
+- 阿里云
+- 蚂蚁
+- 政务平台
+- 大文娱
+- 盒马
+- 阿里妈妈
+- 钉钉
+- 天猫超市、天猫国际、阿里健康、农村淘宝、淘宝心选
+
+
+
+## 未来规划
+
+- 支持更多端，现在主要支持了React，Rax，未来会考虑支持小程序
+- 支持更多组件体系，比如Antd Mobile、Material Design等
+- 支持更完备，可实际用在生产环境中的的Schema表单配置器
+- 在集团内部落地更多场景
+
+## 对社区的期望
+
+我们希望社区更多的参与进来共建，如果觉得文档不完善，可以参与完善文档，如果觉得代码有问题，可以提PR修复
+如果希望我们能支持更多场景，也可以提Feature Request
+
+我们的知识是从社区而来，我们也有必要赋能社区，帮助社区更好的运作下去。
+
+
+## 团队介绍
+
+Formily属于集团中后台开箱即用战役中的核心子项目
+
+项目组长：元彦，大果
+
+核心维护人(参与者)：白玄，鬼鼠，黄子毅，云数，玉门，载溪，锦此，秋逢，晓松，浅末，松屹