开发工程

组件源代码存放在新FGUI工程
开发调试时在B端Weex工程内进行开发，目录内会新创建一个Git Submodule为FGUI工程，并处理好依赖

开发分支

  1. 在自己fork的BWeex项目内基于fgui分支自行创建fgui_<组件名称>分支, 例如: fgui_fglist
  2. 更新工程内的git submodule工程fgui（分支为develop）
  3. 在fgui工程下的packages目录创建对应组件名称的文件夹，例如packages/fg-list,进行开发
  4. 开发完成后在fgui目录下提交组件源代码到fgui工程的develop分支
  5. B工程的业务替换改动提交到fgui_<组件名称>分支,然后提交merge到fgui分支, 并@相关同学, 最终review通过后合入主库

    组件依赖

    不应依赖其他三方库, 例如lodash, 可以自行在fgui/utils/index.js中添加通用便利方法
    注: 组件导入依赖需使用相对路径, 例:../utils

    组件目录

    ``` |packages/fg-<组件名称>/index.js //*入口文件 |——————————/index.vue //组件代码 |——————————/xx.vue //组件的子组件 例如:item.vue |——————————/type.js //一些常量 例如:LOGO_URL,DEF_Width |——————————/utils.js //不通用的便利方法,该组件内部自己使用 |——————————/xxdata.js //自己使用的一些数据 例如: citydata.js |——————————/xx.js //可自行创建一些封装 例如: format.js

|——————————/demo.vue //组件demo ```

注: 组件目录内的文件名称保持简洁, 例如fg-list不推荐使用~~fg-list-item.vue~~, 推荐item.vue

组件实现规范

考虑到未来扩展的问题，以及我们目前无法确定最优方案，所以我们按照最稳妥和易修改思路去做，对于原生和weex都预留出空间，若以后遇到问题在做减法，所以
对于weex component组件

  • 原生部分创建新类继承自WeexSDK自带类，名称前缀FGUI
  • 注册组件时，注册名称使用weex组件名称加上-native
  • weex创建组件名的.vue文件，内部使用上一步的组件，即xx-xx-native

例如组件fgui-text

  • 原生： 创建原生类FGUITextComponent继承自WXTextComponent
  • 原生： 注册fgui-text-native名称的组件，原生类使用FGUITextComponent

  • Vue: 创建fgui-text.vue,内部透传组件fgui-text-native

    例如使用场景fg-input
    原生类FGUIInputComponent新增参数支持实时效验正则参数formatpattern
    fg-input.vue新增参数type，支持效验phone,email，内部实现是在vue层配置默认的formatpattern

    组件文档模板

    链接

开发流程

开发前:

  1. 准备好开发方案, 开发方案包含
    1. 组件文档: 参考模板”组件文档”
    2. 实现方案: 阐述组件的实现思路、设计方案. 若为原生Component, 至少阐述实现原理
    3. 准备替换的业务: 自行在B端寻找替换业务页面, 在方案评审中确定
  2. 在开发方案评审时一起评审, 根据评审状态做调整并重新评审

  3. 评审通过后进入开发阶段

    开发后:

  4. 自测源码、demo、替换业务正常.

  5. 检查组件文档, 更新组件文档
  6. 提交merge, 需包含
    1. 提交组件源码
    2. 提交Demo源码
    3. 替换业务源码
  7. 根据review评论修改代码, 直至review通过
  8. 合并后交由业务方使用

    维护和更新

    由组件开发同学维护和更新, 待后续有需求时在完善规范

参考三方库

Vant
uni-app
Ant Design Mobile
WeexUI