模型驱动 - (1)前端组件

模型驱动的话题有三个章节：

1、前端组件

2、模型及数据适配

3、后台模型管理

MIS系统中核心是对数据的增删改查，字段很多
而我们的客户需求常常会变化：“等这块有数据后，这里的单选要改成下拉多选框。数据再多就要带搜索哦。”

模型驱动的意义在于提高开发效率，相对于模板产生大量垃圾代码（如：codesmith），模型驱动生成的页面可维护性要更好，但学习门槛也会变高。

目前实践下来 表单、表格、搜索 是可以基于模型和一定规则的排版形成界面的，举例：

表单 - 基本形式：

1. 为了美观一般都会按照规律进行排布
2. 每个小白框都是一个输入类型的控件，会有很多种类型，如：文本、单选组、上传 等等
3. 需要表单校验 及 提示信息，尤其会出现动态改变校验条件，如满足几个输入项后，再必填某项
4. 字段值联动
5. 表单会分组显示
6. 可以嵌入模态弹窗中
7. 移动端一般都只是平铺

搜索 - 基本形式：

1. 搜索仍然是各类输入组件
2. 少数出现需要联动选择的情况
3. 搜索条件，后台可能是多表联合查询。搜索时字段名需要做处理，否则后台判断比较吃力

表格 - 基本形式：

1. 表格列需要可以控制排序、筛选
2. 搜索主要与表格结合，查询条件常驻等
3. 表格数据后端分页
4. 表格编辑时，控件会有对应输入类型

有多少种组件类型，够用吗？

参考 Ant.Design 前端组件库已经很丰富了的，但我们仅需要常用的将其集成。表现形式太复杂的可以作为扩展 Slot 形式在具体项目中自定义。

根据常用表单输入的需求归纳如下图：

组件是否可以更换？

每次谈到这个话题，一种场景就是如果在3-5年后新的组件出现，产品是否可以代价较小的更换？
我的结论是：这个就是扯淡，当每个组件都更换了，整个产品UI都变了，甚至可能连技术栈都换了，何谈代价较小

而我认为比较实际的是，组件库在运行过程中需要更换其中一些组件时，比如：树组件的性能太差需要更换。是否可以对现有产品影响范围最小。

这个问题一直像把达摩克利斯之剑悬在我们头上。需要能够向后兼容就必须预先定义接口。

根据公司使用的主流技术Vue作为框架，定义了tg-turing库来实现抽象的表单、表格、搜索；将真正的组件实现剥离到另一个库，便于之后的更换。

在实际项目中使用的是tg-turing中定义的接口标签组件，以做到升级、更换组件而上层应用无感知。

每个可以接入的表单组件定义为一个ConnectItem：

完整定义可以参见：

可以看一个简单的例子：

let fields = [
    {"name":"WID","xtype":"text","caption":"WID"},
    {"name":"ACCOUNTID","xtype":"text","caption":"登录账号","dataSize":40}
    ...
]

<tg-form :fields="fields" v-model="formData" :column="2" :readonly="true"></tg-form>

另外我还发现mozilla也有一个类似的react项目，它的重心是在表单数据结构上，支持循环嵌套，挺有意思。

下一章来说说怎么使用模型来驱动前端组件