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

我心飞翔 分类:javascript

背景概述

项目介绍

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

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

项目的产品思路:

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

担任的角色和贡献

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

开发过程

需求分析

业务痛点

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

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

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

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

image.png

技术设计

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

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

达成的成果

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

小总结

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

时间上由于对项目还有不熟悉的点,避免不了在中间会多花点时间,这个在评估开发计划和估时的时候需要做好准备。项目完成之后对不熟悉的点做好记录总结,避免由于相同的问题再多花时间。

技术上写的组件包发布工具和封装的类对象,思考如何更通用,作用于更多场景。

业务上,通过数据说明因为帮助用户做了自动处理的逻辑,让用户减少很多操作负担,提升了产品的周活数,这种功能模式值得思考应用到其他模块特性上。


Photo by Marek Piwnicki on Unsplash

回复

我来回复
  • 暂无回复内容