记一下数据可视化大屏选型的前期

2019-03-17

开篇闲扯

说来也是有意思,想想自己当初入坑前端的原因就是因为前端的能够实现的界面效果很炫(我相信很多人也都是因为)才入了这个坑,但是后来的开发离这些炫就越来越远,工作后就没几次开发过炫的界面,换了工作的坑位之后,没想到又有机会回到了当初的“原点”,开始负责数据可视化大屏的开发。接下来就记录一下这次前期的一些想法和技术选型。

整体的一个瞎想

一开始是想要自己实现一个框架来进行开发,想法总是美好的,但是不知从何下手,于是就先用原生的写法,将antv、echarts、d3、动效组件整合在一起进行使用,看看会怎么使用。

发现其实想要的很简单:

  1. 元素写为组件
  2. 组件位置、宽高、层级
  3. 组件渲染

从这里入手的话,那还是回到了现在最流行的几种框架的选型,react、vue、angular、preact,但是现代的前端框架意图挺明显的,通过数据来管理状态、状态管理视图,但是数据可视化大屏并非强交互、多状态,因此没有必要引入现代前端框架进行选用,所以放弃了现代框架。

但是组件的设计实现、模板写法、jsx语法糖是可借鉴的,组件的编写、组件的复用才是要解决的事情,想过造个轮子,但是前期做这些工作,投入的时间和最后的回报不成正比,因此想到了之前的一个前端框架 svelte

svelte的介绍就不展开了,有兴趣的小伙伴可以自行点击这里进行了解,接下来说说我选择的原因。

组件化

svelte 同样是web component的一种实现,组件的编写方式与vue类似。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<p>
The time is
<strong>{hours}:{minutes}:{seconds}</strong>
</p>

<script>
export default {
data() {
return {
time: new Date()
};
},

computed: {
hours: ({ time }) => time.getHours(),
minutes: ({ time }) => time.getMinutes(),
seconds: ({ time }) => time.getSeconds()
}
};
</script>

采用单文件组件的形式进行编写,官方也提供了用于构建单组件的模板component-template,只是一个基础模板,可以根据项目的不同自行定义。

构建时

svelte 采用的是构建时(build time),也就是说在最后编译的代码中不包含svelte本身,而是一种更接近Vanilla JS的结果,这也是当初选择的主要原因之一,肯定会有人说,虽然这能够减少框架本身的体积以及现代前端框架的运行速度已经接近原生JS的执行速度,以及VisualDom的算法已经非常快了,但是针对数据可视化大屏的业务类型,较少的会出现需要现代框架能力,而且svelte本身也具备了数据-状态-视图的能力,在数据可视化大屏的场景中,今后最大的瓶颈应该是资源的加载、动效、动画加载和执行上的问题。所以构建时的这种选择对于我们来说是一种比较理想的选择。

组件化其实才是最大的需要,其它的问题其实都比较好解决,相信经过之后的迭代会有一套我们自己更利于构建数据可视化大屏的框架。

可视化图表、视觉元素

可视化图表的选择应该没有太大的问题,其实最主要的就是拓展性,尤其是样式方面的拓展,因此选择了antv、echarts、d3,后来发现antv和d3的可玩性更高,具体还没实践过,只是根据官方文档来推断的。

视觉元素的做法就是使用canvas、svg+css animation 来说实现了,我们会分两种方式,UI设计师先负责设计,前端再跟进,前端未进行实现的元素可以先使用动图、图片或视频的来替代,但是这样做会牺牲一些文件体积,以及放大后的失真。

自适应

借鉴datav的思路,可以指定画布的基础分辨率,但是假如实际屏幕有一些不同的话,那么通过scale的方式按比例进行缩放,这样就可以做到一定程度上的自适应,因此前面提到的svg就能很好的来做到不失真。

瞎想图

image

结语

这还只是第一步的瞎想,接下来需要先根据这个进行一个数据可视化大屏的实现,发现还要学习的内容还有好多,前端的架构、计算机图形学、动效、canvas、svg、WebGL等等相关的内容都需要进行补充。路漫漫其修远兮,吾将上下而求索。

下面是我的微信

欢迎骚扰

ww1o01