前言

“怎么改？”“什么时候改？”，“什么时候支持这些功能？”。

我又一次沉默了。如何改变是我想的。最近一直忙于其他问题，暂时没有处理。我也想在请假的时候好好想想。

半年前接触到el-form-renderer，瞬间觉得大部分的表单编写工作都减少了。一个简单的JSON配置立即显示了一个功能完善的表单页面。但是随着使用频率的增加，各种不足逐渐暴露出来，组件的作者也不再单独维护组件。由于项目表单场景的需要，我们叉了一个版本，但后来发现我们更想要的是一套自己的表单渲染规则，于是我们在Github的组织下建立了自己的代码仓库@ femmessage/el-form-renderer(以下简称El-form-renderer)，并开始了自己的维护。

3W

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

什么？

表单呈现器基于元素-用户界面封装，但不仅仅是元素-用户界面，甚至不仅仅是表单。

为什么？

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

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

做b级车生意的同学应该深受感动。我们每天都需要面对大量的操作或者表单场景，所以只要是能够从这些重复的CRUD中解放出来的解决方案，就是最好的解决方案

我们的目的也很简单，这样世界上就没有难的形式了。

至于为什么是el-form-renderer，原因很简单。我们没有让难的表格变成现实，目前至少在几十个项目中，我们已经解决了70%以上的表格需求。

怎么做？

如上所述，如下图所示：

需要以良好形式解决的问题：

表单的值、分配和验证

形成联动

自定义表单项目

表单项的事件、属性和槽

足够用户友好

所谓“下层基础决定上层建筑”，我们不坚持从0开始，而是“让专业的人做专业的事”。基本组件element-ui足够专业，正是因为它的专业性，才可以使用原始版本的el-form-renderer。但目前远远不够的是，我们没有很好地处理好表单链接、表单项的事件、槽等问题，这正是我想思考的。

基本用法

让我们看一下我们当前的实现(请参考文档了解更多信息)

模板El-form-renderer label-width=' 100px ' : content=' content '//templatescript import UploadToAli from ' @ femessage/Upload-to-Ali ' export default { data(){ return { content : [{ $ id : ' avatar '，label3360' avatar '，component: UploadToAli}，{ $ id: ' username '，label:' user name '，$ type: ' input '

不需要复杂的逻辑，只需配置JSON就可以实现常见的表单功能

解决办法

因为它不是从0开始的，所以作者的设计只服务于element-ui的现有组件。

之前的计划解决了什么

表单的值getValue，赋值updateValue

完全继承了元素的表单属性，包括验证

表单链接$enableWhen

大多数简单的场景都已经介绍过了，但是它们仅限于元素ui组件。动态组件选项(如下拉选项)的问题处理不好，无法进行批量赋值。必须手动删除空格.

当前方案优化了什么

支持定制组件，摆脱对元素ui的完全依赖(仍然依赖于它的el-form，el-form-item)

通过setOptions方法，动态处理组件选项

添加批量更新数据方法updateForm，并添加trim来处理该值

为了方便其他组件的集成和设置/获取值的要求，还增加了输入格式和输出格式(问题)

它已经完成了一次华丽的转型，甚至成为了我公司零部件的桥梁阵地。然而，面对各种各样的要求，这真的是不够的。

存在的问题

目前的七期大致可以分为以下几类：

形成联动

自定义插槽位置

自定义事件

其他优化

需求告诉我们，还有很大的提升空间。

思考

回到开头的话，我们应该如何处理存在的问题？

今天收到公司同事的公关，处理el-form-renderer中的槽位问题。默认情况下，它只是默认的，显示在最后。需要在某个表单项目之前/之后显示它。PR将表单项的$id作为命名槽，并在相应的$id表单项上方呈现槽内容。

这是个好主意，但也让我想了很多。可能还是不符合我的要求。

考虑另一种情况。需要在表单的第一个和第三个呈现上方呈现两个具有相同内容的槽。根据上面的想法，我们应该编写两个模板，并定义它们要呈现的位置的$id。

以上问题不难解决。定义一个字符串匹配规则，或者在某个配置项中添加一个要渲染的槽，如果名称匹配就进行渲染，从而达到重用的目的。

问题好像解决了，问题可以关闭了，但是我们回去想想，为什么要自定义槽位呢？

因为这个问题，一些用户有这个需求。

那他为什么会有这个需求呢？

我们不知道，场景很多，但可以大胆猜测，没有满足他渲染需求的组件，他需要一个槽来定制显示内容。

因此，似乎我们需要的不是一个槽，而是我们缺少那些组件，或者我们需要一个更通用的渲染方法来渲染我们的内容。很容易想到渲染。如果我们返回一个渲染，似乎大多数问题可以关闭。然而，事实是，我们从一开始就不想渲染，因为它一点也不友好，甚至对一些人来说，它也不简单，这不是我们的目的。我们的目标是让它更容易使用和理解。就像我们的文档一样，简单却实用。

很多公关，或者打算提公关的，忽略了一个问题。我们的组件不支持事件，所以很难实现？不会，至少绑定属性已经实现了，绑定事件也没那么难，但是不支持，因为我们在思考它的必要性，表单项是否真的需要绑定事件。

我从一开始就说过，它不仅仅是元素ui，甚至不仅仅是形式。我们的目的不纯。我们正在寻找一个总体方案。如果支持事件，表单项和业务代码之间的相关性肯定会更强。这不是我们想看到的。至少在目前可以看到通过可视化界面生成表单的前提下，我们不希望有自定义事件的需求，这就使得我们通过可视化界面生成表单不太通用。

那么，在目前的情况下，真的没有办法解决这些问题吗？答案是否定的。

我们知道，我们可以通过自定义组件来扩展表单项，因此我们也可以通过自定义组件来解决遇到的问题

从“”导入自定义组件。/custom-component ' export default { data(){ return { content :[{ label : ' username }，component: CustomComponent，$ id:' username '，$ el: {placeholder : '请设置您的登录用户名' } } }]} }或者在一些更简单的情况下。

从“”导入uploadtoali。/UploadToAli ' export default { data(){ return { content : [{ $ id : ' avatar '，label:' picture '，component : { data(){ return { imgurl : ' ' } }，render : function(h){ return h(UploadToAli，{ prop : { value : this . imgull }，On 33: { input :(val)={ this。imgur=valthis。$ emit ('input '，val)}}，[h ('p '，{slot3360' spinner'}，'开始上传.')])}}}记住前面提到的对用户友好和渲染的东西。目前可以解决问题，但不是好的解决办法。解决这个问题没那么难。难的是能够友好够简单，这是我们一直努力的方向。

结论

我写了很长时间都不知道.

通过配置实现表单似乎是个好主意。目前公司中后台已经试用了几十页。但是业务场景是千变万化的，我们不可能100%的解决需求。然而，我们希望我们的方法能给可配置表单带来更多的想法。

抛砖引玉，最后贴仓库地址：https://github.com/FEMessage/el-form-renderer,希望更多的方案和实施浮出水面，解放生产力。再次感谢原作者

摘要

以上就是本文的全部内容。希望本文的内容对大家的学习或工作有一定的参考价值。谢谢你的支持。