关于前端:单据架构实现页面可配置化

本篇是对以前工作中的单据架构实现做的总结，目前工作中我负责的零碎也从零开始实现了这套架构性能。

👉“单据”：金融、外贸行业术语，货运单据

👀以前做外贸行业的 SaaS 软件，表单字段数量之多，没接触过的人必定难以想象😮。当初在金融行业工作（也有物联网、互联网服务行业工作教训），感觉外贸、财务、金融行业的业务相对来说复杂度更高🎨，技术实现上也更加简单（👉没有接触过的请先理解一下再发表意见😊）。就比方本篇要讲的表单，不是设想的几个表单字段提交那么简略，除了外围的业务数据字段还波及到十分多的行业术语字段，整体复杂度一下子晋升很多，而且单据类型多样，传统的在页面上堆字段的开发方式显然不实用了🤔。所以，就开始在 根底业务架构 上进行摸索翻新，创意须要想象力，感兴趣请看下文👇

1、应用场景及性能

1.1、应用场景

可用于常见任何表单性质的页面，筛选字段组件等。

1.2、性能

1. 页面可配置化（整体成果）
2. 款式排版可管制（horizontal / vertical）
3. 增查修 性能三位一体
4. 碎片化批改
5. 字段联动展现
6. 字段参数预置
7. ……

2、前置思考

最基本的还是 组件开发，并在此基础上给组件赋能，采纳自下而上的设计。

1. 复合组件 + 扩大组件 + 自定义组件
2. 组件开发三要素：属性、事件、办法
3. 组件的关系：依赖、联动

4. 数据字典：业务字段 + 业务字典

   • 业务字段设置: 用于配置页面须要显示的字段信息
   • 业务字典设置: 用于字段枚举值获取显示

5. 业务组件： -> 架构

   • 类似的业务流动
   • 应用相似的数据
   • 具备通用的解决流程
   • 通用的业务指标
   • 是密切联系的组织单元
6. 最初, 模块划分, 后端采纳 RESTful 接口设计格调, 实现 CRUD

3、开发流程拆解

1. 根底控件开发（“小池子”）

   • 初始化数据填入（带入值回显）：initVal()
   • 更新：updata()

   • 批改事件：change()

     • 联动数据标记：$emit(‘handleReletedFields’, xxx, xxx)
     • 批改 controlData 得值，用于收集输出值。值类型个别是字符串、数字、布尔值、数组（多选时）
   • 重置数据：reset()
   • 移除校验：initVal 办法里 执行 clearVerfy() – this.$refs.form.clearValidate()
   • 必填项校验：verifyForm() prop 属性

   • 控件数据获取：

     • 获取码值配置数据 – 业务字典
     • 一般接口获取业务数据
     • vuex 存储的码值数据
   • 收集控件并裸露给收发组件应用
   • 排版款式解决

2. 控件收发管制（“三通”）

   • 以动静组件形式实现数据流的收发
   • 初始化数据：initData()，调用根底控件的 initVal()办法，或者 updata()办法
   • 重置数据：reset() 调用根底控件的 reset()办法

   • 提交数据：submit()

     • 调用根底控件的 verifyForm()办法验证必填项，如果没有填写，则进行滚动定位到须要填写的组件(offsetTop)
     • 控件输出值收集：提取各个业务字段的 controlData 值，组装表单信息

   • 数据联动：handleReletedFields()

     • 调用联动控件的 initVal()办法实现数据联动

3. 具体业务组件（数据流“主管道”，总线）

   • 业务字段信息组装，props 传递给收发管制组件
   • 提交数据：submitForm() 调用收发管制组件的 submit() 办法，拿到业务字段输出信息。

4、控件参数（业务字段配置）

上面是单个控件的参数配置, 🧨要实现整个页面的可配置化, 须要配置业务字段

{
  "fieldLabel": "控件名称"，"showLabel": true, // 是否显示 label
  "fieldName": "appId",
  "controlName": "SingleSelectDownBox",
  "controlData": "","defaultValue":"",
  "defaultOptions": "","localVuexDictData": true, // 控件数据是否从 vuex 里获取"remoteDictOptionsData": false, // 控件数据是否从接口里获取"remoteOtherApi":"", // 独自接口获取，在 api 外面定义的名称，采纳策略模式应用
  "labelWidth": "100px",
  "rightWidth": "220px",
  "labelPosition": "right",
  "isNotNull": 0,
  "placeholder": "","dictKey":"OperateTypeEnum","keyCode":"dictCode","controlSize":"100%","column":"1","readonly": false,"relatedFields":"platformCheckStatus=platformCheckStatus;"// 多个关联字段用; 宰割"clearable": false,"editable": false
}

4.1、页面业务字段配置示例

5、联动字段配置阐明

"relatedFields": "platformCheckStatus=aaa;customField=bbb"

// 或者
"relatedFields": "platformCheckStatus=platformCheckStatus;customField=customField"

platformCheckStatus=aaa

• ”=“右边的platformCheckStatus，示意以后字段要关联的字段名称，
• ”=“左边的aaa，示意回传信息的键名，用于确定关联字段要显示的值。

const info = {
  aaa: 'xiao',
  bbb: 'xixi',
  // platformCheckStatus: '',
  // customField: '',
}
this.$emit('handleReletedFields', info, this.itemData.relatedFields);

6、字典值配置

多用于单选、多选、级联框备选项数据，以下是 字典数据结构👇

data: [{
    "alias": "scale",
    "dictCode": 2,
    "dictItems": [
        {"dictItem": [],
            "dictItemCode": 1,
            "id": 512323,
            "inUse": 1,
            "itemEnName": "1-5 people",
            "itemName": "1- 5 人",
            "itemValue": ""
        },
        {"dictItem": [],
            "dictItemCode": 2,
            "id": 512324,
            "inUse": 1,
            "itemEnName": "6-10 people",
            "itemName": "6-10 人",
            "itemValue": ""
        }
    ],
    "dictName": "规模",
    "id": 2,
    "moduleCode": "A001",
    "sortOrder": 0
}]

最初

架构设计要遵循三个设计准则:

1. 不多也不少 (架构都是适宜过后的状况, 解决过后的问题, 重要的是不做过多设计, 这是一个陷阱)
2. 演进式 (依据变动及时改良和调整架构)
3. 持续性 (本身的能力也是逐渐晋升的, 设计的时候须要为将来改良留下肯定的空间)

我是 甜点 cc

酷爱前端开发，也喜爱专研各种跟本职工作关系不大的技术，技术、产品趣味宽泛且浓重。本号次要致力于分享集体经验总结，心愿能够给一小部分人一些渺小帮忙。

心愿能和大家一起致力营造一个良好的学习气氛，为了集体和家庭、为了我国的互联网物联网技术、数字化转型、数字经济倒退做一点点奉献。数风流人物还看中国、看今朝、看你我。