蓝鲸项目组:奖项申报-前端 部分的小总结
项目背景
奖项申报系统是为了解决组织的奖项管理,提供有组织管理,创建奖项,申请奖项,撤销奖项,批量通知,批量邮件发送等功能,同时基于蓝鲸平台,利用蓝鲸平台提供的用户管理能力,以及大平台效应(也就是基于蓝鲸 Paas,一个账号多个系统都可以使用),使得该系统能作为一个 Saas 应用,可以提供给各个组织使用。
按照所完成的 issue 对自己所写代码的复盘总结
issue #8: 完成组管理和奖项管理前端页面开发,调整完善部分代码
代码文件总览
👆 这是当时修改的文件(看着改了 32 个文件,其实 每一个组件的添加对应有一个无用的
index.css
)
除了基本配置项设置的改动:router
、App.vue
、package.json
。
组管理模块
文件夹总览
关于组管理模块放置在group-manager
文件夹下面,命名规范 大写驼峰法,以文件夹区分,实际文件命名为 index
,对于页面代码位于直接模块文件下的 index.vue
样式位于 index.css
,组件同理,这样做的好处是为了,在引用的时候只需要 import GroupManager from '@/views/group-manager'
,组件同理,同时为了区别组件,以及如果组件通用与多个页面,因此在页面下单独创建文件夹为 components
,这是关于组管理页面的文件夹设计,起初在DialogArea
组件中是为了抽离公共 layout
,设计出不同的内容表格,但是后续发现确实这两个弹框没有后续发展的必要,但是为了后续弹框的扩展,于是还是设计了一个 index.js
来暴露我所写的弹框组件。
表单部分
由于表单比较单一,于是我采用 tableSettings
来遍历,通过 prop
注入的方式来实现中间部分的表单设计,这样使得中间部分的风格统一,这种一般适用于纯数据展示,当需要动态的配置表单数据时更方便,可以隔离开数据主体,但是同时遇到的问题也很明显,如果中间有一个字段需要做一些特殊处理的时候,就很麻烦,于是我设计了一种组件(当然这个没有在这次项目中使用上):
1 | <bk-table> |
其次是在操作的时候,将 refs['EditorDialogForm']
作为参数传入,让对应的方法更加独立开,而不是依赖与 this
然后是表单数据处理的时候,我将所有处理数据的逻辑放置在 computed
中:
这样做的原因,是因为我希望将 computed
的数据响应性,用作为数据过滤加上字段别名配置,在以后开发中,如果遇到字段不一致,需要更改的时候统一到 computed
中去修改就行,而不影响到之前所配置的字段。
弹出框组件
弹出框组件中,我起初的设计都是通过双向绑定,将通过 attrs
传入或者通过 props
传入,然后这次项目中,我将这些数据都通过调用组件的 show
方法,然后将数据传入:
这样让一些关键的表格判断,在组件内部可能会更加单一,比如如果传入的数据 id
不存在,这种情况下,表格显然不允许有弹出,而是给一个报错警告,于是我就转为这样去设计组件了,(当然具体是否合适,貌似我后续的开发中,发现这个确实不是很合适)。
逻辑层面
我抽离了一个公用方法,临时放置在 created
(图片中的写错了 😒),然后在点击按钮,触发一些还在开发的功能中,临时放置,这是我之前开发中的一个习惯,就是未实现的功能,不放空,而是给到一个警告和报错信息。
adjustTable
以及notImplemented
都放置到mixins
中
奖项管理模块
文件夹总览
还是和之前一样的 index.vue
加上 components
,表单设计和组管理中的表单设计
是一致的,
弹出框组件
控制诸如新增奖项
、批量发送邮件
、批量克隆
、展示高级筛选区域
这一类,只是做为中间函数的代码(因为考虑到如果有些弹出的数据需要处理)的代码统一放置在弹框控制区
对应的弹出框组件,以及对应的表格,均通过组件的方式进行,抽离,统一化,因此需要修改对应的表格在对应的组件去更改就好。
对应源代码所在的文件夹
在这个文件夹下面的 index.vue
,放置有弹出框的主体样式,其余的 Form
就是对应的中间表格,单独抽离出来,是为了让弹出框的样式更加统一(不一定是弹出框,侧边栏也是),
其余组件
自定义表单,是因为批量克隆中,会用到一个表单,但是表单不能来自于组件库,因为这样样式不会带到富文本中去,会出现一系列的问题,然后是Editor
使用了wangEditor
Editor
需要注意的是 this.$nextTick
,因为 wangEditor
的实例依赖于Dom
,所以使用了 $nextTick
,其次还有一个方案,可以利用$el
,在mounted
后,el
会被替代为当前的组件。起初计划的是使用 v-model
,但是想了一下,貌似没必要不断的去刷新组件,所以就转成了 👇
但是这个组件有以下个问题:
wangEditor
包太大,后续可一寻找一些轻量级的xss
是不必要的,因为我发现util
中写了escape
Svg
做统一导出了,虽然没有必要,因为确实没有用到太多的 Svg
,图片 Svg
在这里去配置,因为 Svg
是一个相对比较新的东西
feature: 奖项展示与申请、组管理与奖项管理,与后端协调并实现接口调用与具体样式优化 #15
代码文件总览
这次主要涉及到很多公共信息的抽离修改
utils
主要是一些用于抽离出的公共工具方法,
Stores
这个模块主要放置组内人员,有很多页面都会用到
这一部分放置了,关于奖项级别的状态信息。
Detail
关于可申请奖项的申请表单和详情表单,同时组合在index.vue
作为组件使用。
Mixins
对于分页,由于接口调用趋向于一种通用的趋势,变体只有 url
,和对于的 tableData
字段,于是我开始做抽离,让一些可复用的参数放置在上面,方法的话,算是使用了模板,但是鉴于 Mixins 的使用一直存在一些畏惧,所以一些辅助的功能放置在 Mixins中,然后对于 fixMixins,我将一些Bug 的解决方案,放置在 fixMixins 中
开发中用到的一些下次开发的资产工具(除了代码上)
- 由于只有原型图,于是绘制了一份 Figma 的关于 magicbox 的 UI 组件库(仅绘制自己使用到的一些)
遇到的问题以及解决的问题
总结(以随记的方式记录一些关于项目的思考)
- 组件的抽离思路,从可复用、可扩展和易用的方向去设计,但是究竟怎样去实践才是更好的呢,比如我在组件设计中,发现越做,越让一个组件扩展了太多的功能点,让组件反而难以维护,或者说当需求变动的时候,让这个组件可能出现崩溃的浪费。
axios
的封装思路computed
的getter
和setter
的一些技巧
来自一年后的穿越总结
- 不要再写
notImplemented
这种东西啦,自己找一个小本子记下来就可以啦 - 函数啥的多加点注释
来自两年后的穿越总结
- 如何理解组件化,本质而言,去理解状态,也就是说,实际上实在做状态树,将状态变更最多的单独做成一个组件。