解放前端工程师——手把手教你开发自己的自定义列表和自定义表单系列之一缘起

2021-06-12

> 之前有序言章节<Vue中路由到一个公共组件,然后根据路径中是否存在文件动态加载组件>,已经是一个雏形了。而现在,重新梳理下,我们要做的是让前端工程师不用上班了,哈哈,这么贴心的后端哪里找?

1、终极需求

产品经理A:“经常有些需求,并不是那么复杂,可能仅仅是增删改查,做些验证,为啥总要时间开发?”

后端甩锅王: “我开发很快的,但是! 每次做需求的时候,总需要前端童鞋的协助,他们总是很忙~~~”

产品经理A:"既然都是类似代码,那有没有可能让开发的童鞋歇会呢?"

后端甩锅王心里一万头神兽掠过,这是要 让程序员不写代码啊!, 不写代码的程序员还是程序员吗?

好吧,我就静静的看你装B!

后端甩锅王:“我想到了个方案,可以 让前端程序员不写代码!”

产品经理A:“好棒耶,去干, ta!”

2、组件规划

既然决定不需要前端人员参与,就能搞定一个模块。 那我们就做个通用模块的增删改查就好了。

当然根据产品经理的“需求的发展”,也许需要多个不同类型的组件,满足各类奇葩需求。

我们就用最简单的列表(按钮),同页面增删改查方式实现一个。
大概的界面如下:
在这里插入图片描述
一个模块需要的基本的功能都有了:

  • 增加(增加按钮,弹出页面)
  • 修改(修改按钮,弹出页面)
  • 删除(弹出确认提示)
  • 搜索,可以搜索定制列
  • 分页,展示多页

2.1 面向约定开发

根据这些功能,我们提取变化的地方到配置中。
配置里尽量按照约定来约束后端的开发 , 仅把模块名视作变化量。

  • 接口命名按照增删改查的动作+模块名 来定义
  • 提供公共接口,入参:模块名,出参:该模块的下配置(列表、form表单)
  • 后端配置 前端页面的路由,并由前端整合到路由表内。
    这里路由信息 参见序言文章.
    views/common/index 就是我们的公共入口
{
  path: '/test',
  component: Layout,
  hidden: false,   
  meta: { title: 'test', icon: 'dashboard' },
  children: [{
    path: 'testa',
    name: 'testa',
    component: () =&gt; import('@/views/common/index'),
    meta: { title: 'test1', icon: 'dashboard' }
  },
  {
    path: 'testb',
    name: 'testb',
    component: () =&gt; import('@/views/common/index'),
    meta: { title: 'test2', icon: 'dashboard' }
  }
]
},

2.2 预留前端开发入口

为了给前端童鞋留条活路(应对复杂的需求变化),我们心存善良的留下了前端参与的方式。

如果前端童鞋开发了该模块的功能,那我们就客气的使用吧

 var path = this.$route.fullPath
  try{          
       this.realCompoonent =  require(`@/views${path}`).default
       //this.$router.push(this.realCompoonent)
   }
   catch(ex){
       console.log(`load sub com [${path}] failed. ${ex}`)
       this.realCompoonent = null
   }

2.3 减少Ctrl+C\V

因为预留了扩展接口,前端童鞋又可以快乐的 Ctrl+C,Ctrl+V了,有没有什么办法救救孩子们?

嗯嗯,明白了,虽然需要定制,可能也只是某些部分吧,那我们能不能多预留几个slot呢,嗯嗯,这种方式是可以的。

我们采用了另外的方式,引入了mixList.js ,在这里定义了公共组件大部分功能, 扩展的瘦,仅需要引用 mixins:[mixList],即可继承所有的方法, 看那个方法事件不满意,都可以重载覆盖它们,.

嗯嗯,好了吧,

2.4 动态加载配置

按照2.1章节,我们已经预定了所有的配置和模块名强相关,那么我们需要做的就是怎么解析到 模块名,并传送给公共组件?

眼见的童鞋们,应该发现了路由路径上就是最好体现模块名的地方,那我们就约定路径的前2个节点为模块名,.
把模块名组织好,传给后台, 然后一切的配置都由后台决定了。

至此,前端的工程师们可以躺平了!
在这里插入图片描述

3. 后端开发

之前已经聊过,后端只需要按照约定开发相应的接口即可。

后端甩锅王:“做完了这个需求,我咋发现我自己被套路了,这下需求再完不成,就没办法甩锅前端了!oooop,我要失业了!”

当然开发这个需求还是不容易的,后端童鞋可以收藏下,毕竟本次也没法一次写完,后续会不断更新。

大致先欣赏下前端的配置界面。
在这里插入图片描述

3.1后端表设计

  • 先定义一个模块全局表
    在这里插入图片描述
  • 定义列表配置表
    在这里插入图片描述
  • 第三个就是form表单配置表

在这里插入图片描述
最后一列可以保存为json格式的数据,这样每个控件都有了自己可以定的属性了。

看到这里的童鞋,祝贺你,你已经进入了PASS设计的领域。

3.2 后端接口开发

接口仍在开发中,相信从数据库的设计,童鞋们应该可以自己动手撸代码了。
> 前端工程师们,别慌,你可以顺便做做PASS平台的开发了!

4.后记

产品经理A:“经常有些需求,并不是那么复杂,可能仅仅是增删改查,做些验证,为啥总要时间开发?”

后端甩锅王: “我要写代码才能完成啊?”

产品经理A:“既然都是类似代码,那有没有可能让开发的童鞋歇会呢?”

后端甩锅王:“................#$#%^^%@#!”