Luban-Dashboard 简介和背景介绍

[ly525]

Dashboard 这个词很少会翻译，如果翻译的话，一般业务上指：首页、Hompage、入口之类的页面，和大屏项目也有些类似。

需求

在业务开发中，我们经常需要一个 Dashboard/首页/仪表盘/大屏，我们经常遇到的需求是：把 Mysql 中某个几个表的数据，查询24小时/一周/一月/一季度，做成几个趋势图，放在 Dashboard 里面

痛点

1. 简洁模式：
   只有老大的一两句话，和产品的一些简单截图，就要快速开发了。开发完成之后，需要频繁调整（可能产品此时都不知道自己想要的图究竟长什么样，应该先用 datav 做一下的，或者找设计师做设计稿，但没得）

2. 正常模式：产品收集需求、方案讨论、设计稿、开发、调试、上线

经常会涉及到一些痛点需求：

 1. 图表位置经常调整
 2. 图表样式调整
 3. 图表之间联动

思路改变

之前：

1. 眼界不够宽阔

在我经常开发 B端报表的时候，因为之前没有接触过（没用过） 阿里云的 Datav、360的即视、BDP等产品，因此对这方面认知比较浅，对业内比较不错的 Dashboard、BI 工具了解较少

2. 之前的工作方式比较简单暴力，没有总结、沉淀、反思：

很长一段时间做Dashboard 就是为了做而做。大量的时候花在了调整Echarts 参数上，回过头来重新看，发现很多调参的细节都已经忘记了。加之对 echarts 很多地方做了定制化，导致不同的项目，无法进行统一和抽象，不同项目之间的代码无法复用。有类似的项目或者需求，因为不同项目后端接口返回的数据格式不同，因为前端没有Adapter，导致前端代码和后端接口耦合严重！

3. 对业务场景缺乏总结

自己负责的好几个项目都有 Dashboard，自己之前都没有主动想过这些业务场景有哪共同之处，有哪些是可以抽象做统一的。导致代码和思路都非常分散，类似的需求，甚至因为时间的演进，写法会有很大不同，返回重构之前的代码，都成了痛苦的体验

现在：

在实际使用了 即视(360)、阿里云-DataV、BDP 之后，有非常强烈的感受：

1. 其实里面大部分的场景，我们平时开发感觉也能遇到，这时候就会想：是否可以把这里面的业务场景抽象出来，做成运营可配置、拖拽的的。

2. 然后对自己之前的工作有非常强烈反思：完蛋了，自己貌似从未想过怎么把平时写的这种业务场景做成更抽象、更通用的组件或者类 [Facepalm]

3. 比如折线图：大部分同学感觉都做过，我做了很多了，但从来没想过：
   3.1. 是否能把 折线图的 输入格式/规范 做一个约定吗？
   3.2. 不管数据源是什么，是否有想过中间写一个适配层(Adapter)，把各种数据 经过适配层(Adapter)之后，得到的数据格式是统一的，这样直接 把格式化之后的数据，输入给「约定输入规范」的折线图，就可以渲染了，落地成伪代码大概思路如下

   -> Ajax(折线图API) 
   -> response 
   -> Adapter 
   -> DataSet(某种格式的数据) 
   -> new LineChart(DataSet).renderChart(domElement)

4. 已经按照上面的思路进行编码落地，在实际中项目中积累常见的业务场景

展望

可以参照 即视(360)、阿里云-DataV、BDP 等产品，对上面的流程进行进一步的优化

 -> 配置数据源：接口、Adapter
 -> Ajax(折线图API) 
 -> response 
 -> Adapter 
 -> DataSet(某种格式的数据) 
 -> new LineChart(DataSet).renderChart(domElement)
 -> 图表拖拽配置数据源之后，添加至Dashboard
 -> 在 Dashboard 中可以拖拽调整位置
 -> 再进一步：Dashboard 结合 下拉菜单、单选框等，进行多图表联动、过滤查询
 -> 突然感觉这货里面又内嵌了一个：表单生成器 😂