Formily

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 中，我们抽象了整个表单领域模型，同时这个模型又是一个无限循环状态机。

在 Formily 中，主要有三种开发模式，主要是：

• JSON Schema 开发表单
  • 该方案主要用于后端动态渲染表单
• JSX Schema 开发表单
  • 该方案主要用于后端动态渲染表单的过渡形态，Schema 在前端维护，方便未来迁移后端动态渲染模式
• 纯 JSX(源码) 开发表单
  • 该方案主要用于纯前端开发方式，或者在前两个方案的自定义组件内部的开发以复合形态来开发.

更多教程

化繁为简，开箱即用 | 阿里经济体Formily开源表单方案建设
MegaLayout - 下一代Formily表单布局解决方案