业务组件库 vue2.7 行动目录

本贴最后更新于 398 天前,其中的信息可能已经斗转星移

一、概述

为了提高部门整体应用开发效率,降低维护成本,加强组件的复用,我们计划开发 Vu2.7 业务组件库,并将之推广至整个部门。

该组件库将提供一系列高质量、可定制的业务组件,为各个应用提供稳定、可靠的底层支持。

二、目标

  1. 开发出一套完整的 Vu2.7 业务组件库,满足部门各应用的通用需求。

  2. 推广该组件库,使部门内至少 60%(暂定)的应用采用该组件库。

  3. 通过组件库的推广,达到下面的目的:

    • 降低应用开发的复杂度
    • 提高开发效率
    • 减少开发成本
  4. 作为一个模版挂载到 GCommon 官方上面

三、需求分析

  • 收集并分析部门内各应用的业务需求,确定共性业务组件

    • 设计调研业务组件库的实际需求(业务组件库文件调查)
    • 发调查问卷给各个前端负责人
  • 研究并借鉴业界成熟的业务组件库,取其精华,纳入到我们的组件库中

  • 确定组件库的技术架构、组件间的关系和组织方式。

问卷调查:https://odocs.myoas.com/forms/XKq4MWPmo1iLJLkN/result

以下调查人数为 13 个人,覆盖了所有应用的前端:

  1. 大家最看重的是性能和文档的完善程度

  2. 相比 vue3.0 版本可以新增一个完整的 demo 项目
    对于组件的稳定性也有一定的作用

  3. 希望参与开发的有:素灵、魏泽、政希、何列、莹倩、文波

  4. 需要提供的组件(确定加入边界讨论的加重

    • 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

  1. 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 日

  2. 组件文档的规范

    1. API 表格规范

    1. API 部分应该遵循参数、事件、方法、插槽、类型定义的顺序,若某一项缺失则跳过;如果组件有特殊项需要说明,需要在类型定义后面编写。

    2. API 表格的标题,组成格式为:Xxx [参数 | 事件 | 方法 | 插槽]Xxx 为组件名字,采用大驼峰书写,需要注意组件名字后面加一个空格,标题等级为三级;类型定义标题的格式为 Xxx 类型定义,组件名字同样为大驼峰格式,中间同样需要加一个空格,标题等级同样为三级,具体类型名字跟随在后面用四级标题定义。

    3. API 表格表头和内容应该左对齐。

    4. 参数表格需要具备的列名及顺序为:参数名、类型、默认值、说明、跳转 Demo。

      • 参数不需要使用反引号。
      • 类型需要使用反引号包裹;类型需准确,简单枚举值类型可直接列出来,复杂一些的类型可以写类型名字(如 SizeType),然后增加锚点定位;参数基本类型采用首字母小写 string,自定义类型名字采用大驼峰命名,(如 SizeType)。
      • 默认值不需要反引号包裹,如果默认值为字符串或者枚举类型,应该使用单引号包裹,若无默认值则用双横线 -- 表示。
      • 说明中需要标注该参数为必选还是可选。
      • 跳转 Demo 中的链接需能够正确跳转,并且 demo 中需要展示对应 API 的用法;若无展示 Demo,则空白展示。
    5. 事件表格需要具备的列名及顺序为:事件名、回调参数、说明、跳转 Demo。

      • 事件名不需要使用反引号。
      • 回调参数需要使用反引号包裹;类型格式为 Function(name: string)
      • 跳转 Demo 中的链接需能够正确跳转,并且 demo 中需要展示对应 API 的用法;若无展示 Demo,则空白展示。
    6. 方法表格需要具备的列名及顺序为:方法名、类型、说明。

      • 方法名不需要使用反引号。
      • 类型需要使用反引号包裹。
    7. 插槽表格需要具备的列名及顺序为:插槽名、说明、参数。

      • 默认插槽也需要做说明,并且插槽名字应该为 default
      • 参数为组件内部暴露出来的数据。
    8. 类型定义需要使用 typescript 代码块,代码块格式为 type xxx = yyy

    2. 组件 API 规范

    1. 命名方式用中划线风格:组件的参数名和事件名统一使用中划线格式。
    2. 组件名称前缀:组件的命名统一使用 gas 前缀。
    3. 针对需要双向绑定的参数,需要直接用 v-model,避免增加额外参数,例如 v-model:xxx
    4. 原生支持的属性尽量不再用 API 去单独声明,直接通过 attrs 透传即可,比如 placeholder

    3. 演示 demo 规范

    1. 演示 demo 需要对所使用的 API 及组件默认行为和样式等进行尽可能详细的说明。避免让用户自己去推测,降低用户学习和使用成本。
    2. 每个组件的第一个 demo,应该是组件最基本的用法,即展示组件在不传参数或者传入最基本参数情况下的效果。后面的 demo 应该尽可能按照参数的使用频率来排序。
    3. ***==每个 demo 所展示的 API 应该尽量精简,尽量不要一个 demo 中展示多个 API 的用法。==***
    4. 文案描述需清晰,尽量参考 element 的文案描述,尽量避免口语化;标点符号使用需正确;文案中若涉及到英文单词,需在单次左右两侧加一个空格。
    5. 演示 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
    

  • Vue.js

    Vue.js(读音 /vju ː/,类似于 view)是一个构建数据驱动的 Web 界面库。Vue.js 的目标是通过尽可能简单的 API 实现响应的数据绑定和组合的视图组件。

    266 引用 • 665 回帖 • 1 关注

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...