一、概述
为了提高部门整体应用开发效率,降低维护成本,加强组件的复用,我们计划开发 Vu2.7 业务组件库,并将之推广至整个部门。
该组件库将提供一系列高质量、可定制的业务组件,为各个应用提供稳定、可靠的底层支持。
二、目标
-
开发出一套完整的 Vu2.7 业务组件库,满足部门各应用的通用需求。
-
推广该组件库,使部门内至少 60%(暂定)的应用采用该组件库。
-
通过组件库的推广,达到下面的目的:
- 降低应用开发的复杂度
- 提高开发效率
- 减少开发成本
-
作为一个模版挂载到 GCommon 官方上面
三、需求分析
-
收集并分析部门内各应用的业务需求,确定共性业务组件
- 设计调研业务组件库的实际需求(业务组件库文件调查)
- 发调查问卷给各个前端负责人
-
研究并借鉴业界成熟的业务组件库,取其精华,纳入到我们的组件库中
-
确定组件库的技术架构、组件间的关系和组织方式。
问卷调查:https://odocs.myoas.com/forms/XKq4MWPmo1iLJLkN/result
以下调查人数为 13 个人,覆盖了所有应用的前端:
-
大家最看重的是性能和文档的完善程度
-
相比 vue3.0 版本可以新增一个完整的 demo 项目
对于组件的稳定性也有一定的作用 -
希望参与开发的有:素灵、魏泽、政希、何列、莹倩、文波
-
需要提供的组件(确定加入边界讨论的加重)
- 403/404
- 审批流程图(4)
- 富文本(4)
- 高性能 table(4):多表头的情况、带横向和纵向虚拟滚动的表格、多个固定列
- select 选择器虚拟滚动(3):带多选、清楚、远程搜索
- 穿梭框(2):带远程搜索、虚拟滚动(或许可以单独抽离作为指令或组件)、有扩展性
- 步骤条(2):和 GCommon 的差别是什么?
联系人:莹倩、何列 - 可视化图表(2):使用 echarts,考虑在组件库中引入的意义
- 自定义表头设置(2):考虑样式和交互是否是一致的
- 超出省略组件(1)(可用于表格当中)
- 变更记录(1) → 波直接贡献出来
- icon(2):考虑必要性
- 适配诺亚空间的下拉菜单(1)
- 可视化配置组件(1)啥样的
联系人: 莹倩 - 人员配置组件(1)啥样的
联系人: 莹倩 - monacoEeditor 编辑器(1):考虑必要性,一款开源的在线代码编辑器,秀萍说只是需要展示和编辑
由上可以得出 vue2.7 组件库边界表格1。
四、开发计划
- 确定开发组件的优先级,看表格 vue2.7 组件库边界表格1
- 组件文档的规范2
- 完成技术开发文档
- 组建团体,确定组件库开发流程
- 确定开发的周期(包括组件库的设计、开发、测试、优化等环节)
在开发过程中,定期进行项目进度评审,确保项目按计划进行
五、推广计划
- 完成组件库的开发后,编写详细的文档和教程,方便开发者快速上手
- 通过内部培训、研讨会、邮件通知等方式,向部门内开发者宣传推广该组件库
- 提供技术支持和答疑服务,解决开发者在使用过程中遇到的问题(确定值班人员?)
- 建立组件库更新机制,定期发布新版本,增加新功能,以适应不断变化的业务需求
人力
六、风险分析
风险类型 | 风险内容 | 对策 |
---|---|---|
技术风险: | 组件库的技术架构选择、组件的稳定性、性能等方面可能存在风险。 | 采用成熟的技术框架,对核心组件进行多轮测试,确保其稳定性和性能 |
推广风险 | 部门开发者可能对新组件库的接受程度不一,导致推广受阻 | ??? |
项目延期风险 | 开发过程中可能遇到不可预见的问题,导致项目延期 | 制定详细的项目计划,预留一定的缓冲时间,同时加强项目进度监控,及时调整计划 |
人力风险 | 需求冲突,业务冲突的时候,开发时间不够分配 | 业务组件库需要作为一个独立的应用级别来处理,不应该游离在应用之外 |
七、需要的帮助
- 换台电脑,现在电脑老快了
八、评估与改进
- 制定详细的评估标准,包括应用使用率、开发效率、用户满意度等方面。
统计一方便向领导报告 - 在推广过程中定期进行评估,以了解组件库的实际使用情况和存在的问题。
单独的项目空间开发给用户使用提 issue
vue2.7 组件库边界表格
组件名称 优先级 截止时间 tiptap 富文本 p0 12 月 30 日 审批流程图 p0 12 月 30 日 附件 p2 12 月 30 日 评论 p2 12 月 30 日 虚拟滚动组件(可用于 Select) p1 12 月 30 日 超出省略组件 p0 12 月 30 日 icon p1 11 月 30 日 ==403/404== p0 已完成 变更记录 p2 1 月 30 日 步骤条 p2 12 月 30 日 展开收起 p2 11 月 30 日 优先级选择器 p2 11 月 30 日 标签选择器 p2 11 月 30 日 表头自定义设置 p2 1 月 30 日 穿梭框(带表格) p0 1 月 30 日 高性能表格 p2 1 月 30 日 组件文档的规范
1. API 表格规范
-
API 部分应该遵循参数、事件、方法、插槽、类型定义的顺序,若某一项缺失则跳过;如果组件有特殊项需要说明,需要在类型定义后面编写。
-
API 表格的标题,组成格式为:
Xxx [参数 | 事件 | 方法 | 插槽]
,Xxx
为组件名字,采用大驼峰书写,需要注意组件名字后面加一个空格,标题等级为三级;类型定义标题的格式为Xxx 类型定义
,组件名字同样为大驼峰格式,中间同样需要加一个空格,标题等级同样为三级,具体类型名字跟随在后面用四级标题定义。 -
API 表格表头和内容应该左对齐。
-
参数表格需要具备的列名及顺序为:参数名、类型、默认值、说明、跳转 Demo。
- 参数不需要使用反引号。
- 类型需要使用反引号包裹;类型需准确,简单枚举值类型可直接列出来,复杂一些的类型可以写类型名字(如
SizeType
),然后增加锚点定位;参数基本类型采用首字母小写string
,自定义类型名字采用大驼峰命名,(如SizeType
)。 - 默认值不需要反引号包裹,如果默认值为字符串或者枚举类型,应该使用单引号包裹,若无默认值则用双横线
--
表示。 - 说明中需要标注该参数为必选还是可选。
- 跳转 Demo 中的链接需能够正确跳转,并且 demo 中需要展示对应 API 的用法;若无展示 Demo,则空白展示。
-
事件表格需要具备的列名及顺序为:事件名、回调参数、说明、跳转 Demo。
- 事件名不需要使用反引号。
- 回调参数需要使用反引号包裹;类型格式为
Function(name: string)
。 - 跳转 Demo 中的链接需能够正确跳转,并且 demo 中需要展示对应 API 的用法;若无展示 Demo,则空白展示。
-
方法表格需要具备的列名及顺序为:方法名、类型、说明。
- 方法名不需要使用反引号。
- 类型需要使用反引号包裹。
-
插槽表格需要具备的列名及顺序为:插槽名、说明、参数。
- 默认插槽也需要做说明,并且插槽名字应该为
default
。 - 参数为组件内部暴露出来的数据。
- 默认插槽也需要做说明,并且插槽名字应该为
-
类型定义需要使用
typescript
代码块,代码块格式为type xxx = yyy
。
2. 组件 API 规范
- 命名方式用中划线风格:组件的参数名和事件名统一使用中划线格式。
- 组件名称前缀:组件的命名统一使用
gas
前缀。 - 针对需要双向绑定的参数,需要直接用
v-model
,避免增加额外参数,例如v-model:xxx
。 - 原生支持的属性尽量不再用 API 去单独声明,直接通过
attrs
透传即可,比如placeholder
。
3. 演示 demo 规范
- 演示 demo 需要对所使用的 API 及组件默认行为和样式等进行尽可能详细的说明。避免让用户自己去推测,降低用户学习和使用成本。
- 每个组件的第一个 demo,应该是组件最基本的用法,即展示组件在不传参数或者传入最基本参数情况下的效果。后面的 demo 应该尽可能按照参数的使用频率来排序。
- ***==每个 demo 所展示的 API 应该尽量精简,尽量不要一个 demo 中展示多个 API 的用法。==***
- 文案描述需清晰,尽量参考
element
的文案描述,尽量避免口语化;标点符号使用需正确;文案中若涉及到英文单词,需在单次左右两侧加一个空格。 - 演示 demo 自定义 class 样式,命名格式为
xxx-demo-yyy
(xxx 为组件名,yyy 为自定义样式名),不然会成为全局样式,有可能影响其他组件或者 demo 效果。
4. 编码规范
使用丽云的
5. 组件目录/文件规范
参考
element
源码文件my-component ├── index.ts // 组件入口文件 └── src // 组件源码 └── components // 子组件 ├── my-sub-component.ts └── composables // 组件的逻辑部分 composable ├── my-use-component.ts ├── my-component-types.ts // 组件类型文件 ├── my-component.scss // 组件样式 └── my-component.tsx // 组件
组件类型文件:
import { PropType, ExtractPropTypes } from 'vue' export const myComponentProps = { myProp: { type: Number, default: 1 }, myProp2: { type: Array as PropType<number[]>, default: [5, 10, 20, 50] }, } as const export type MyComponentProps = ExtractPropTypes<typeof myComponentProps>;
6. 样式命名规范
在
use-namespace
文件中,封装了样式命名的相关方法。样式命名采用 BEM 规范,use-namespace
提供了如下几个方法:// 以 Button 组件为例 // 创建 Button 组件的命名空间 const ns = useNamespace('button'); // 根组件一般采用此命名 ns.b(); // gas-button // 组件内的块元素样式命名,即 BEM 规范的 Element 部分 ns.e('content'); // gas-button__content // 组件的修饰类样式命名,即 BEM 规范的 Modifier 部分 ns.m('primary'); // gas-button--primary // 块元素和修饰类样式组合使用 ns.em('content', 'primary'); // gas-button__content--primary
↩
-
欢迎来到这里!
我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。
注册 关于