slickgrid.js 一种高性能web数据表格组件的探讨

本文将探讨一种高性能web数据表格组件的实现,首先简单介绍slickgrid这个前人开发的组件,接着对该组件的设计和实现思路进行讨论,最后对该组件的思想进行提炼,实现基于原始思想的新组件。

slickgird

slickgrid是一款高性能的web数据表格组件,由mleibman于2009年5月提交到github,仓库地址https://github.com/mleibman/SlickGrid。该组件近几年已经停止开发,最后一次提交是2016年5月,但是之前的提交已经是2014年。虽然组件本身的开发已经停止,但是留下了非常丰富的grid组件思想。slickgrid的主要特点如下:

  1. 高性能:slickgrid采用了局部渲染的机制,对于整个数据表格而言,真正对用户有用的,是可视区域的表格,因此,slickgrid只渲染可视区域的表格,从而节省了大量DOM渲染操作,性能上几乎是目前市面上知名grid组件里面最好的。
  2. DataView:slickgrid里面提供了一个DataView的工具,它独立于grid本身,虽然grid本身就可以完成数据的展示,但是为了数据的更多可操作性,DataView提供了更加丰富的操作空间。同时,这一思想把界面操作和数据操作分离开,虽然在现在看来已经非常老套,而且代码层面也很落后,但是在当初那个时代,还是非常先进的。
  3. 语言性:slickgrid并不是完整的UI组件,并没有提供直接的接口一次性完成所有配置,它具有语言性,也就是提供基础的语法,你可以用它的语法和素材,不断按照自己的需要进行组合,如果它内部没有实现,你可以自己另外写一套代码,和它混淆以后使用。总之,它就像一堆积木的块,构建出什么样的grid功能就看开发者如何利用它提供的块组合起来。

当然,这些特点并不全是优点,几乎每一个点都有可诟病的地方。不过,这种思想是对技术的一种提炼,已经非常难能可贵。

grid的构成元素

现在,我们从头思考,一个数据表格,它应该由哪些元素构成。数据表单最基本的元素是单元格,也就是cell,是单点数据的展现方式。一个数据节点被存放在一个cell中。cell的父级是行,也就是row。整个数据表格就是由很多row堆叠而成。row是数据展示的主要部分。但是除此之外,还有表头,也就是指示列信息的columns信息,它指明了同一行中,相同索引的cell的共同特征。这些是grid中最为基础的元素。

问题是,就像slickgrid中给人的想象一样,我们并没有必要把所有的cell渲染出来,而是只渲染当前可视区域的数据。这种思想基于数据量很大的假设。当然,即使是小数据量,这种设计也是应该兼容的才可以。因此,我们需要设计一种对可视区域和渲染的抽象概念。这就是viewport和canvas。

viewport是用于提供给用户的可视区域的视口,就像浏览器视口一样,只提供这么大的窗口大小,至于内部网页的实际大小,是无法通过该视口直接观察到的,必须通过滚动条来感知。而对于数据可展开的实际大小,就是canvas的大小。canvas的意思是画布,也就是说是绘制cells的地方。canvas的实际大小应该是假设所有数据一次性绘制完成时所占用的空间大小。当然,这里说假设,意思是我们实际上并不一次性绘制完所有数据,而是只在canvas的viewport遮盖区域内进行绘制。所以它们的关系是:

grid中viewport和canvas的关系示意图

上图中的阴影部分是无法用肉眼看到的,只有viewport内部是可以被看到的。在web开发中,通过overflow来轻易的实现滚动条,从而可以通过拖动viewport的滚动条查看canvas的每一个位置。

canvas作为gird绘制视图的对象,grid的cells和columns将会被绘制在canvas中,因此,从这个层面讲,canvas虽然只是绘制的载体,但最终包含来grid的基础元素,因此被视为一个整体。在开发时,将基础元素和canvas打包成一个实体,不需要再去考虑内部但row和cell。

另一个问题是,columns可能被固定在grid的顶部,滚动视图时,不会被遮盖。除了columns,在实际使用中还有一些需求,要求左侧、右侧、顶部、底部固定一些真实的数据信息,而不是columns。这样的需求衍生出另外一个思考,就是需要将完整的grid视图拆分为不同的区块,这些区块有的可能被固定在某个位置,但是所有这些区块组合起来让用户可以看到符合逻辑的完整的grid数据信息。而这种拆分,我认为用另外一个概念来表达:layout。

layout意思是布局,表示一个grid按照一定的思想被切分,按照特定的规则把切分开的部分合理组合在一起。为了满足实际的需求,我将grid layout切分为3x4的12个部分,如下图:

grid layout示意图

header部分区别于neck、body、footer,因为它只用于展示columns信息。它的结构可能在一些细节上稍有不同。

为什么要这样设计呢?它可以满足如下需求:

  1. 横向滚动时,left、right可以被fixed,从而实现左侧、右侧的数据列固定
  2. 纵向滚动时,可以固定header、neck、footer,实现特定的头、行固定需求
  3. 当只需要简单结构,不需要固定时,隐藏对应区域即可,例如不需要固定左侧,则left所有区块hide,不需要footer,hide即可,最为简单的grid可能仅显示header-middle和body-middle。

每一个区块拥有自己的viewport-canvas结构,区块本身实际上仅对应区块本身的数据(包括columns)而不包含其它区块的数据展示,因此实际上grid没有一个完整的展示所有数据的机会,只有这些区块全部正确展示数据时,才能正确把grid反应给用户阅读。

这里提出的grid layout和很多其它的grid组件存在本质的区别,很多组件采用的是fake概念,也就是将表格复制一份,左右展示。笔者曾经使用过dhtmlx,是一个非常笨重的grid组件,它不仅代码量大,而且无法清晰的解释如何实现我上述提到的需求。它会告诉你,自己是如何实现左侧固定列的,但是无法告诉你一种通用的固定策略。

最终,一个grid的组成可能是这样的结构:layout->viewport->canvas->rows->cells

滚动事件

我们需要去研究,用户滚动滚动条的目的,当然很简单,是为了看非可视区域的可预判性数据。但是当我们把整个grid切分为12个区块之后,滚动变得有些复杂,如何简单有效的去设计表格的滚动呢?

实际上,header总是被固定的,当用户滚动滚动条时,其实并不希望表头消失,否则他很难确定可视的数据的列信息。而left, right, neck, footer这几个区域本身也是为固定设计的,因此,实际上在滚动时,这几个区域根本也不会发生本质的变动,最终,body-middle这个区域才是滚动条的作用区域,只有这个区域是任何滚动事件发生时都应该发生变化的。而left、right这两个区域在左右滚动时保持不变,header、neck、footer这三个区域在上下滚动时保存不变。通过观察,我们发现header-left, neck-left, footer-left, header-right, neck-right, footer-right这些区域是永久固定不变的。

基于上面的这些观察,实际上,我们要考虑如何安排滚动条的位置。最终,我将滚动条放在body-right的右侧,footer-middle的底部。

当右侧的纵向滚动条发生滚动时,整个body区域的视图发生上下滚动;当底部的横向滚动条发生滚动时,整个middle区域的视图发生左右滚动。整个滚动事件就这么简单。

在代码层面,我们需要实现滚动的联动效果,也就是滚动滚动条时,其它区块的viewport发生相同的滚动效果,或者在非滚动条区域,比如在body-middle滚动鼠标滚轮时,其它区域也同时发生联动效果。

数据布局

前面所讲都是视图布局,数据如何按照视图布局的需求,进行拆分和处理呢?实际上,在web开发中,数据可以仅存在一份,相互之间可以引用。我们更关心的是,在全部数据中,layout里的viewport应该获得哪些数据用以渲染,这些数据最终决定来该viewport内的canvas的大小。这里,我们引入一个新的概念:range。

range表达了一个数据区域,即从第几行到第几行、第几列到第几列的数据区域。用代码表示为{ fromRow, toRow, fromColumn, toColumn }这样一个对象。

我们需要在两个地方有明确的range概念:1. 每一个layout区块的range,2. canvas的可视区域的range。

layout的range用以构建canvas,而canvas的可视区域range用以渲染。layout的range完全是用户传入的,比如用户想固定前2列,那么left区域的range一定有{ fromRow: 0, toRow: 1 },而这两列的宽度可以通过columns信息中得到,这样left区域的宽度就可以确定了。同样的道理,其它区域的尺寸也可以通过类似的方法确定,最终剩下的区域就用总的尺寸去减去已知的区域尺寸。这样下来,layout基本就有了固定的尺寸,再将scrollbar考虑进去,视图布局就确定了。viewport尺寸也跟着确定。

canvas的尺寸和layout差不多,但是不同的是,它必须知道完整的layout的range信息,因为canvas是通过真实的数据得到尺寸的,所以在传入的配置信息中,你必须告诉canvas rowHeight信息。如果没有rowHeight信息,无法得到canvas的尺寸。一般columns里面包含了width信息,所以宽度信息基本是不用担心的,如果不存在,那么也必须传入一个columnWidth信息。

canvas的可视区域的range则需要viewport把当前scroll信息传递给canvas,再由canvas利用自己的数据信息计算出具体应该渲染出哪些行哪些列。而当滚动事件发生时这个计算过程需要反复发生,渲染也会反复发生,这是不可避免的代价。不过,我们可以做很多缓存的工作。

数据驱动

我们摒弃slicgrid中DataView的概念,转而使用DataDriver的概念。数据层和视图层分离是注定的,对于数据的操作会引发视图的联动效应,这也是注定的。对于开发而言,开发者只需要关心数据如何变得即可。例如新增了一条数据,修改了一条数据,删除了一条数据。这些操作仅仅需要在数据层完成,完成数据操作之后,视图会自动更新。

这在当代开发中非常用以实现,react、vue、redux、mobx都是非常好的思路。问题在于,有没有必要为了实现数据驱动而去加载其它的库,增加代码量?

另外一个话题是,如何设计数据结构。从结构上,我们还是遵循slickgrid的当初的设计,colunms、rows。数据视图采用扁平的rows结构,由于是局部渲染,我们必须采用position:absolute绝对定位,无法使用float等布局方法,因此无法用display等css属性来删除列之后又显示出来。这种操作只能通过修改数据来做到。因此rows信息包含两个层面,一个层面是原始数据,另一个层面是视图数据。grid真正要展示的是视图数据,但是原始数据是视图数据的根,因此,如何在两者之间管理好,是一个大问题。

最后还有一个问题,是数据节点的父子关系,一条数据是另外一条数据的子节点,这种数据结构怎么来表达?我们采用来扁平的rows结构,所以,只能通过增加_parent, _chidren属性等属性来表示引用。当展开一个带有children的row时,我们需要想办法把这些children从原始数据中加载到视图数据中。而收起一个parent的时候,也要实现从视图数据中删除。

总结

本文最大的创新,是在grid layout上,它非常优雅的解决来冻结行列问题。slickgrid本身并没有考虑到这个层面,冻结列是在slickgrid的一个fork中实现的,不是它的核心库。然而在现代web数据表格中,冻结行列几乎是必备需求。另外,本文没有探讨的一个问题是编辑问题,也就是用户可以在线像编辑excel一样编辑自己的数据表。我认为,这个话题需要引申出另外一个话题,就是组件的插件/扩展机制,如何在原有功能上实现简便的扩展。

2017-12-11 | ,

为价值买单

向我捐赠1-5RMB