基于vue通用表单解决方案的思考与分析-创新互联

前言

“那要怎么改？”，“那得改到什么时候？”，“什么时候才能支持这些功能？”。

再一次听到了这样的话，我沉默了。到底要怎样改，这也是我所思考的，最近一直忙于其他，已经有一段时间没有处理 issue 了，趁着调休，我也要好好思考下。

半年前，接触了 el-form-renderer  ，瞬间感觉减轻了大部分表单编写的工作，一个简单的JSON配置，立刻展现出一个功能完好的表单页面。然而，随着使用的频率增加，却慢慢开始暴露各种不足，该组件的作者也不再单独对该组件进行维护了。由于项目表单场景的需要，我们 fork 了一个版本，但后来发现我们更想要的是一套属于我们自己的表单渲染规则，于是在我们的 Github 组织下建立了属于我们的代码仓库 @femessage/el-form-renderer  （以下都称为 el-form-renderer ），并开始了我们自己维护之路。

3W

el-form-renderer 是什么？为什么？怎么样？通过3W分析来看看我们做了什么。

WHAT？

基于 element-ui 封装的 表单渲染器 ，但不仅仅是 element-ui ，甚至不仅仅是表单。

WHY？

这里的为什么有两层，第一层是为什么需要表单渲染器？第二次是什么是 el-form-renderer ？

借用《NoForm - 一个更好的表单解决方案》中的一句话：

做 B类业务 的同学应该深有感触，我们日常需要面对大量操作类或者表单类的场景，因此只要是能从这些重复的CRUD解放出来的方案，就是最好的方案

我们的目的也很简单，让天下没有难做的表单。

至于为什么是 el-form-renderer ，理由很简单，我们正在让没有难做的表单变成现实，至少在目前数十个项目中，解决了70%以上的表单方面的需求。

HOW？

如上文所说，如下图所见：

一个好的表单需要解决的问题：

•表单的取值、赋值、校验

•表单联动

•自定义表单项

•表单项的事件、属性、slot

•对用户足够友好

所谓”下层基础决定上层建筑“，我们没有执着于从0开始，而是“让专业的人做专业的事”。基础组件， element-ui 足够专业，也正因为它的专业性，才让 el-form-renderer 最初的版本有了用武之地。然而目前远远不够的是，我们没有很好的处理表单联动和表单项的事件、slot的问题，这也正是我所要思考的地方。

基础用法

先来看看目前我们的实现（更多请参考 文档 ）