重构一个可配的查询统计到底有多难?|每日热门

背景

查询统计，可以说是任何业务系统都必备的一个工具。也是很多公司给新人熟悉业务练手的一个系统。

【资料图】

它的前端业务逻辑一般比较简单明了。设置几个输入条件，根据输入条件生成调用参数，通过后端接口生成报表。

这样一个系统维护起来难度并不大，但是往往随着报表的增多，工作量很大。因此我们需要设计一个可根据配置自动生成报表页面的查询统计前端。这样前端的工作量就可以大大减少，节约了前端开发的资源。

基础实现

这个查询统计到我手里时，已经实现了既定的功能。下面我们简单看一下原来的功能和代码结构。

原来的实现大致可以分成三个模块。

上方是导航栏，是可配置的菜单。

中间是查询条件，也是不同报表间最大的区别。我们希望这个区域能修改成可配置的。比较常见的查询方式有时间，输入框，下拉框，下拉框树等。此外还包含一个查询和重置的按钮。

下方是ureport的报表，由后端生成。

那么我们看看原来的代码实现：

菜单实现

菜单的实现可以说已经非常的不错了，抽象出了一级菜单name，code，icon，二级菜单通过parentCode确定挂载在哪个一级菜单下面，点击时通过routeCode路由到对应查询组件页面。

扩展开发痛点

相信大家看到第三张图，也就是我们已有的报表组件时，就会发现原来实现的问题。

其一：报表数量太大了，后续维护管理，包括项目上二次开发回归代码，都存在巨大的工作量。

其二：新增报表时修改工作量也不小，首先复制一个已经做好的报表，然后在上面修改字段，在路由中添加这个组件。一个报表前前后后修改的工作也不少。

模板生成查询条件

首先需要定义的是我们模板的数据结构，他应该包含报表名字，报表code，报表的url路径，查询字段，报表归属菜单等主要属性。特别需要注意的是下拉框，下拉框树这种查询条件，需要配置字典来源Source。当然还可以包括排序，是否展示等辅助属性。routeCode咱们复用一下原来的实现。新增一个template模板组件，通过配置生成的报表统一路由到这个模板组件展示。

按照这个思路我定义了TemplateItem这个模板数组。同时顺手把title和菜单配置也一起单独拉出来，为了后续进一步优化做准备。

首先要把模板生成的菜单和原有的菜单兼容，通过设置sort属性来排序。这样就可以在不破坏原有实现的基础上追加新功能。

在路由切换时，需要缓存一下点击进入了哪个模板，这样打开模板页面时才能根据缓存的数据生成页面。

模板组件

前面的工作完成后，那么模板组件的实现也是水到渠成了。

根据field生成查询条件，采用flex布局，一行六个条件，自动换行。

除了时间，输入框，下拉框，下拉框树等之前说的查询条件，这边还新加了两个type，space代表一个空的区域，便于调整页面布局，query代表查询和重置两个按钮。

展开来看，里面是各个查询的具体实现，非常的简单，唯一值得一提的是里面的各个code不是写死的，采用queryData[xxxCode]这样的形式去绑定。下拉框内的字典来源基本采用了原有的实现，我这边加了个GetSource的方法，根据Source配置的key获取字典定义。

最后

既然json定义好了，也能根据json生成页面了。那么最后一步显而易见，我们把这个json放到数据库里，在页面打开时通过后端查询获取。那么前端的工作量就彻底消灭了。将来再有新的报表需求，前端版本发布完后不再需要再在前端修改。后端完成报表后根据字段填写json即可实现前端查询条件模板的自动生成。当然我们甚至可以更进一步，提供一个维护页面，通过可视化的界面去输入字段name code，选择source type。这样现场的工程人员可以直接通过操作页面来生成json。

感想

比较大的前端项目也从零开始做了三四个了。在做前端产品的时候，我最大的感受就是我们不能仅仅局限于我们亲自去实现一个页面，也要让没有前端编程经验的人，甚至是没有编程经验的工程人员参与进来。当他们在现场接到需求时，我们可以赋予他们一点实现需求的能力。这样的实现才能说是一个好的实现。

标签： JSON 编程算法