报表可视化搭建平台 - 筛选器联动优化 | 项目复盘

背景概述

项目介绍

项目目标: 报表通过可视化搭建的方式，来缩短数据报表开发周期。减少研发同学的依赖，解放生产力。支持 PC 端和移动端展示。

目标用户: BI 分析师、HR 或者效能改进部门。

项目的产品思路:

1. 本身是整个可视化搭建生态中的一员，整个可视化搭建生态底层引擎由单独一个前端小组开发和维护，然后再和业务前端一起共建。比如现在这个项目：报表可视化搭建平台。
2. 整个可视化搭建生态的理念：
   • 不去一个产品大而全，全部把功能包括在内一个产品里面，而是把具体的某个单一场景的事情做好，产品的功能范围清晰，使效能最大化发挥。
   • 设计统一底层的编辑器和渲染器，然后在上面长出审批页面搭建平台、中后台应用搭建平台、报表可视化搭建平台等可视化搭建平台。
   • 同时这些平台可以相互打通使用，比如搭建的审批页面的数据，可以交给报表可视化搭建平台制作报表，进行数据分析。

担任的角色和贡献

项目后端开发 3 到 4 人，前端就只有一个，也就是我自己，所以需要独立负责项目的设计和开发工作。开发初期主要是做一些 UI 交互优化和 Bug 修复的工作，以及协助开发业务专题。熟悉之后逐步对代码进行整理，整理代码文件结构，使用 ESLint 规范代码编写，提取组件公共部分单独发包复用。编写项目开发文档和示例组件，方便其他同学开发自己需要的业务图表组件。项目不断迭代，对产品不断进行功能增强和体验优化，改善用户体验。其中完成过一个大的复杂的需求：筛选器组件与图表组件自动联动，极大的改善了用户体验，提高用户配置报表的效率。

开发过程

需求分析

业务痛点

1. 筛选器组件和图表组件的联动，是指通过筛选器组件来过滤要图表组件要显示的数据。比如 Select 组件，选择某个数据之后，图表组件对应显示这个数据的图表信息。
2. 但是设置筛选器组件和图表组件联动的设置一直都比较繁琐，需要自己编写代码，如果不需要了，还需要自己手动删除。
   • 组件配置改变时（数据集、字段、组件的唯一标识），同时需要修改联动配置。
   • 组件删除时，还需要删除对应的配置。
   • 组件或者页面复制时，联动逻辑要检查配置一下配置，因为组件的唯一标识重新生成了。
   • 在未自动联动前，不同数据集之间的字段时设置不了联动。
3. 这对于用户来说上手和使用成本都比较高。特别是对于没有编码基础的用户。
4. 所以希望优化这部分的设置，根据配置规则自动帮用户处理联动逻辑，降低用户的上手和使用成本。

解决该痛点对应的问题梳理

1. 根据规则自动处理联动逻辑，首先需要有数据，需要哪些数据，怎么去收集这些数据。
2. 要监听哪些事件，监听到的数据是怎么样的，这些事件是不是底层库都支持。
   • 有些数据并不是预期的效果，比如选择字段，只能监听 onChange 方法，返回的是一个列表，还要自己去分辨是新增、删除、还是修改。
   • 有些事件监听不了，比如你不知道组件是新增的，还是复制的，比如你不知道页面是新建的，还是复制的，复制事件比较重要，因为要重新确定绑定关系。
3. 怎么管理和操作这些数据。如果还是按单个 util function 的话，逻辑有点分散，且这样的函数会有很多，不容易管理。
4. 要发布的组件数量很多，如何处理。
5. 同时还需要修复一些小问题和开发小功能，如何协调。
6. 整体功能的工作量比较庞大，如果有序的开发（手动修改配置、筛选器与筛选器之间的配置联动、跨数据集之间的配置联动）。
7. 自动联动之后，用户在界面上是可以看到联动的配置的，如果用户有改动，那么会影响自动联动的判断，所以需要评估如何处理在自动联动之后手动修改。

展示筛选器联动配置体验对比的效果

技术设计

针对上面梳理的问题，设计对应的解决方案：

1. 先搭一个底座。通过发布订阅的方式收集用户操作的事件。例如收集组件新建、选择数据集、选择字符段、删除组件、删除选择的数据集等这些事件。
   • 达不到预期的数据先不做处理，先收集上来，后面再统一处理。
   • 底层引擎不支持的方法，查看底层引擎的源码，给开发小组提 PR 添加需求需要的功能。
2. 主要收集两个数据，分别是：diagramList、filterList，然后根据 diagramList 和 filterList 生成 bindList。然后根据 bindList 生成联动代码和联动配置。这样就是一个自动生成联动配置的过程。这两个数据也作为用户手动修改配置时的数据来源。
   • 
3. 数据操作涉及到很多个方法，所以这些数据的操作方法分模块封装成对应的抽象类，避免逻辑零散，便于开发和维护。它们分别是：AutoBindManager、DiagramBinder、FilterBinder、BindGenerator。对外只暴露 AutoBindManager 对象。AutoBindManager 里面调用 DiagramBinder、FilterBinder、BindGenerator 对象的方法根据联动规则来完成自动联动的功能。
4. 写一个组件包发布工具，写一份组件包发布配置，跑一遍程序，就可以根据配置修改组件包文件并发布对应的组件包。节省大量的组件包发布时间和精力。
5. 这次的代码修改只发布 aphla 版本，避免依赖这个包的组件在安装依赖时，安装这个还有待完善的版本。对于临时插进来的需求，先跟 PM 沟通以及分析估时看如何排期完成，还有协调是否可以有前端同学紧急协助一下（后面也确实加入了一个前端小伙伴一起开发）。
6. 完成需求功能分阶段推进，先支持单个筛选器与单个图表的组件联动，整个实施一遍设计逻辑，调试看有什么问题，记录要修改的点，便于后面修改其他组件。没问题之后，再支持全部的筛选器组件和图表组件。再实现手动修改功能。好了之后这一部分功能也可以先上。然后实现剩余的功能：筛选器与筛选器之间的配置联动；跨数据集之间的配置联动。
7. 手动修改之前需要把自动开关先关闭，然后才可以手动修改。由于已经关了自动联动，所以之后自动联动操作将不处理这个组件的联动。如果用户再打开的时候，再对组件跑一遍自动联动的逻辑，再次由自动联动逻辑重新接管这个组件的联动操作。

达成的成果

功能上线之后，用户上手和使用成本都大大降低，也使得在随后的时间里，产品的周活数稳定提升一倍。

小总结

由于项目代码量很大，牵涉到组件和依赖很多，逻辑点也很多，在开始方案设计的时候，想着这个功能点这样开发是顺的，到了实际开发的过程中发现那那都不顺，改起来也比较费劲，所以整体需求做完的时间大概有两个半月了，很漫长 ...留个小尾巴，明天再写~

Photo by Marek Piwnicki on Unsplash