IIDP前端开发规范

Image not found

前言

希望IIDP开发者通过阅读本手册，能够充分利用IIDP平台进行开发，避免常见的错误和陷阱，写出高质量的代码，提高开发效率。让我们一起码出高效、码出质量的软件系统。

开发规范

命名规范

1.【强制】 组件命名规范，组件名称必须唯一 说明：在IIDP平台中，确保组件名称的唯一性，便于识别和管理。

正例：tech-button / tech-dialog / tech-upload / tech-custom-multi-input tech-作为名称前缀，具体的组件名作为后缀名称。

反例：custom-multi-input 没有tech-作为名称前缀，会导致使用时type：custom-multi-input不显示这个组件

常用的命名规范：

【推荐】小驼峰式命名法首字母小写，大驼峰式命名法首字母大写，短横线连接式，下划线连接式

正例：camelCase/PascalCase/kebab-case/snake_case

反例：formconfiglabelposition 单词直接全小写拼接可读性差

1、项目文件命名

【推荐】命名方法：kebab-case 字母小写短横线连接

正例：whclould-smart-port / my-project-name

反例：My-Project 2、目录名

【推荐】kebab-case，有复数结构时，要采用复数命名法

正例：assets、components、directives、mixins、utils、views 3、单文件组件名 【推荐】单文件组件名应该始终是单词大写开头 (PascalCase)，大驼峰式命名法。

正例：MyComponent.vue

反例：my-Component.vue

4、全局变量，全局方法名称使用应用名称+功能名称

正例: 

const IOT_THEME_OPTIONS = ['blue', 'red', 'green']

function iotGetSearchParams(params){
  console.log(params)
}
反例： const MY_TE = ['blue', 'red', 'green'] 可读性差维护成本高

代码规范

代码参数命名

【推荐】在声明 prop 的时候，其命名应该始终使用小驼峰式命名法camelCase

正例：camelCase

反例：camel-Case

注释规范

注释的原则：提高代码的可读性，从而提高代码的可维护性 如无必要，勿增注释 ( As short as possible ) 如有必要，尽量详尽 ( As long as necessary )

扩展规范

1.【推荐】扩展名称使用应用名称+菜单名+功能名称

正例：iot_iiot_program_menu_search_extend

反例：unit_test_extend_view 不明确生效的位置和功能 2、关于扩展选择的节点id 【强制】在选择扩展的节点id时，对于id中包含undefined的节点，可能是平台的异常，请咨询平台人员

3、样式扩展

【强制】对框架使用的Element的样式修改时，使用局部作用域，以免影响全局样式

4、主题扩展

对页面顶部，侧边栏，菜单等公共模块的扩展 需独立新增app内扩展，可以单独自行安装卸载，以免影响全局

版本管理规范

git commit规范

  1. feat从master拉出，分支保留至release发版

  2. fix分支修复哪个rel就从哪个rel拉出,从哪个rel分支拉的，合并到哪个rel

  3. feat新功能开发,自测成功前每天将master分支合并到feat_xxx分支 自测完成后，到gitlab提合并申请到dev分支

  4. 分支创建规则：

关于版本更新

为了确保线上使用的依赖版本与开发时的版本一致，有以下几项注意事项：

1、执行npm run update:tech、npm run update:beta、npm update等命令升级后依赖版本中会带有 ^ 等符号，如果需要使用固定版本，需要手动修删除 ^ 符号，使用固定的具体的版本号，并执行npm run init:tech重新安装指定版本

2、为了保证打包稳定，请直接使用当前开发环境所安装的依赖，不需要执行 npm run update:tech 或者 npm run update:beta

工程结构规范

1、工程结构说明 

|— apps
  |— base                            // 业务App 根据实际情况命名
    |— common                        // 公共总扩展，一般情况不用操作，后面会展开讲解
      |— common - 公共总扩展
      |— assetImport.js - 内部导入连接资源扩展入口
      |— asset.json - 外部url连接资源扩展入口
      |— common.js - 应用公共配置扩展入口
      |— comps.js - 定制组件扩展入口
      |— extendView.js - 合并视图扩展入口
      |— hook.js - 功能钩子扩展入口
      |— schema.js - 初始视图结构扩展入口
      |— index.js - 公共扩展总入口
    |— views                         // 纯js格式编辑视图，通过视图的扩展能力合并的主视图中
      |— rbacUser                    // 业务定制的扩展视图，名称根据实际情况定义
        |— tview__base__rbac_user.js // 扩展文件，后面会展开讲解 命名规则：[自定义业务名].js
      |— ...
      |— index.js                    // 扩展视图的入口
    |— config                        // 当前App的额外配置，如全局变量
      |— app.json
    |— resource                      // 语言包，皮肤 等资源
    |— static-resource               // 静态资源
    |— index.js                      // 扩展引入入口
  |— component                       // 公共业务组件
|— config
  |— nginx
  |— apps.json
|— build                            // 各种环境的打包入口

2、工程运行起来后，以下文件夹是工程临时生成文件不用处理： resource、static-resouorce、views、dist、distApp、distTmp

测试规范

单元测试

1.【强制】编写独立、可重复执行的单元测试。 说明：单元测试应该是独立的、不依赖外部资源的测试，可以在任何环境下重复执行。确保每个单元测试之间相互独立，不会相互影响，提高测试的可靠性和可维护性。

2.【强制】 测试覆盖率达到预定目标。 说明：测试覆盖率是衡量测试代码覆盖业务代码的程度的指标。根据项目的需求和复杂度，设定合理的测试覆盖率目标，并确保单元测试覆盖率达到或超过这个目标。

3.【强制】 每个单元测试应该只测试一个功能点或场景。 说明：每个单元测试应该聚焦于测试一个特定的功能点或场景，避免将多个功能点或场景混合在一个测试中。这样可以提高测试的可读性和可维护性，并能更准确地定位问题。

4.【强制】 使用合适的测试数据进行测试。 说明：在编写单元测试时，应该使用合适的测试数据来覆盖不同的情况和边界条件，以验证代码在各种情况下的正确性。包括正常情况、边界情况、异常情况等。

5.【强制】验证预期的行为和结果。 说明：每个单元测试应该明确验证预期的行为和结果，通过断言来判断测试是否通过。确保测试代码能够准确地验证被测试代码的行为和结果。

功能测试

1.【强制】验证系统的用户界面（UI）功能。 说明：功能测试应该验证系统的用户界面功能是否符合预期，包括页面布局、交互操作、表单验证等。通过功能测试可以确保用户界面的可用性和易用性。

部署规范

1、底座的更新只能通过更新服务器中前端工程。

2、app 的更新可通过应用市场更新，可也以通过服务器部署更新

3、打包外部依赖 app 和本地开发的 app 到./dist/umdComps中。适用于通过应用市场上传安装

Table of Contents