今天收到一个 PR ，来自公司的一位同事，处理的是 el-form-renderer 中 slot 位置的问题，默认只有 default ，显示在最后，有需求希望能显示在指定某一个表单项的前/后。该PR以表单项的 $id 为具名插槽，渲染该插槽内容到对应 $id 表单项的上方。
一个很好的思路，但是也让我思考了很多，或许它还是没有达到我的要求。
不妨再思考一个场景，表单的第一项和第三项渲染的上方需要渲染两个内容相同的 slot ，按上面的思路，我们应该写两个template，并分别定义他们要渲染到的位置的的 $id 。
上面的问题并不难解决，定义一个字符串匹配规则，或者在某一项的配置项中添加要渲染的slot，名字匹配则渲染，以达到复用的目的。
问题似乎是解决了， issue 可以关闭了，但是我们回过头来想想，我们为什么要自定义 slot 位置？
因为有issue，有用户有这个需求。
那他为什么会有这个需求？
我们不得而知，场景很多，但我们可以大胆的猜测，缺乏一个组件可以满足他的渲染需求，他需要 slot 来自定义展示内容。
所以，似乎我们需要的并不是 slot ，而是我们缺乏了那些组件，或者我们需要一个更通用的渲染方式来渲染我们的内容。很容易，我们想到了 render ，如果我们返回的是一个 render ，那似乎大部分 issue 可以关闭了。然而事实是，我们从开始就不希望出现 render ，因为它一点都不友好，甚至对部分人来说，它不简单，这不是我们的目的。 我们的目的是为了更好用，更好理解，就向我们的文档一样，它很简单，但很实用 。
许多PR，或者打算提PR的人忽略了一个问题，我们的组件没有支持事件，它很难实现？不，至少已经实现了绑定属性，绑定事件并不会多难，但是没有去支持它，因为我们 思考的是它的必要性 ，表单项是否真的需要绑定事件。
从一开始就说过，不只是 element-ui ，甚至不只是表单。我们的目的不纯粹，我们寻找的是通用的方案，如果支持了事件，表单项与业务代码的关联性绝对会更强，这不是我们希望看到的，至少在我们目前可以看得到的通过可视化的界面生成表单的前提下，我们不希望出现自定义事件的需求，它让我们通过可视化的界面生成表单变得不那么通用了。
那么，在目前的情况下，真的没办法解决这些问题了吗？答案是否定的。
已知我们可以通过自定义组件的方式拓展我们的表单项，那么我们也可以通过自定义组件解决我们遇到的 issue
import CustomComponent from './custom-component' export default { data () { return { content: [ { label: '用户名', component: CustomComponent, $id: 'username', $el: { placeholder: '请设置您的登陆用户名' } } ] } } }
或者在一些更简单的场景
import UploadToAli from './UploadToAli' export default { data () { return { content: [ { $id: 'avatar', label: '图片', component: { data () { return { imgUrl: '' } }, render: function (h) { return h(UploadToAli, { props: { value: this.imgUrl }, on: { input: (val) => { this.imgUrl = val this.$emit('input', val) } } }, [ h('p', { slot: 'spinner' }, '开始上传中...') ]) } } } ] } } }
如果从这个层面来说，我们早已经解决问题了，但是那些 issue 依然在那儿。还记得之前提过的对用户足够友好和 render 的事吗，目前来看，它能解决问题，但不是一个好的方案，解决问题并没有那么难，难的是解决了还能足够友好，足够简单，这也是我们一直在努力的方向。
结语
不知不觉写了好长...
通过配置的方式实现一个表单似乎是一个不错的思路，目前已经在公司中后台有过数十个页面的尝试。然而业务场景千变万化，我们没有办法解决100%的需求，但希望我们的方式为配置性表单能带来更多的思考。
抛砖引玉，最后贴一次仓库地址： https://github.com/FEMessage/el-form-renderer ，希望更多的方案和实现浮出水面，解放生产力。再次感谢 原作者