欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

基于vue通用表单解决方案的思考与分析

程序员文章站 2022-08-02 13:35:31
前言 “那要怎么改?”,“那得改到什么时候?”,“什么时候才能支持这些功能?”。 再一次听到了这样的话,我沉默了。到底要怎样改,这也是我所思考的,最近一直忙于其他,已经...

前言

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

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

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

3w

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

what?

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

基于vue通用表单解决方案的思考与分析

why?

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

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

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

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

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

how?

如上文所说,如下图所见:

基于vue通用表单解决方案的思考与分析

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

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

•表单联动

•自定义表单项

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

•对用户足够友好

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

基础用法

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

<template>
 <el-form-renderer label-width="100px" :content="content" />
</template>
<script>
import uploadtoali from '@femessage/upload-to-ali'
export default {
 data () {
 return {
 content: [
 {
 $id: 'avatar',
 label: '头像',
 component: uploadtoali
 },
 {
 $id: 'username',
 label: '用户名',
 $type: 'input',
 $el: {
 placeholder: '请输入用户名'
 }
 }
 ]
 }
 }
}
</script> 

效果如下:

基于vue通用表单解决方案的思考与分析

没有复杂的逻辑,只需进行简单配置 json 的方式就可实现常用表单功能

解决方案

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

之前的方案解决了什么

• 表单的取值 getvalue ,赋值 updatevalue

• 完整继承了 element 的 form 表单属性,包括校验

• 表单联动 $enablewhen

大部分简单的场景已经覆盖,但是局限于 element-ui 组件,没有处理好动态组件选项(如下拉选项)的问题,无法批量赋值,必须手动去空格...

现在的方案优化了什么

• 支持自定义组件,摆脱对 element-ui 的完全依赖(仍然依赖它的 el-form , el-form-item )

• 通过 setoptions 方法,动态的处理组件选项问题

• 添加批量更新数据方法 updateform ,并添加 trim 来处理值

• 为了方便在其他组件中的集成和设置/获取值的需求,还添加了 inputformat 、 outputformat ( issue )

它本已完成了一个华丽的蜕变,甚至成为了我司组件的桥梁地位,然而,面对千奇百怪的需求,它确实还不够。

存在的问题

基于vue通用表单解决方案的思考与分析 

目前的7个 issue ,大致可以分为一下几类:

•表单联动

•自定义slot位置

•自定义事件

•其他优化

需求告诉我们,它还有很大的进步空间。

思考

回到开始的那些话,面对存在的问题,我们要怎么处理好它。

今天收到一个 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 ,希望更多的方案和实现浮出水面,解放生产力。再次感谢 原作者

总结

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