react+antd写表格的selectedRows时遇到的bug

Posted 2023-03-21

参考技术A 这是组件自带的bug,在antd的4版本已经修复了，可是我的是在3版本，所以，还得自己解决。

问题：

    

然后我选其他页的数据，这个selectedRows数组没有加上前一页的数据，导致拿到的值只有当前页的数据。

解决办法：

        二维数组拼接：

而我们可以拿到selectedRows的值，就是我们想要的。

放弃antd table，基于React手写一个虚拟滚动的表格

缘起

标题有点夸张，并不是完全放弃antd-table，毕竟在react的生态圈里，对国人来说，比较好用的PC端组件库，也就antd了。即便经历了2018年圣诞彩蛋事件，antd的使用者也不仅不减，反而有所上升。

客观地说，antd是开源的，UI设计得比较美观(甩出其他组件库一条街)，而且是蚂蚁金服的体验技术部(一堆p7,p8,p9，基本都是大牛级的)在持续地开发维护，质量可以信任。

不过，antd虽好，但一些组件在某一些场景下，是很不适用的。例如，以表格形式无限滚动地展示大量数据(1w+)时，antd-table就特别蹩脚了，光是首次渲染就能卡个五秒白屏。如果这个表格还要求能编辑，甚至不同列之间发生联动呢？对不起，antd-table无能为力，会把页面卡炸的。

antd-table本身是基于rc-table的扩展，而rc-table所属的react-component素来有自己的主张，在react社区其他的组件库都支持无限滚动时(例如react-data-grid, react-virtualized, react-tabulator..)，很抱歉，它不支持。

 爹爹不支持，作为儿女的antd-table也不好反对，顺其自然咯。

于是，部分使用antd的开发者就脑阔疼了，想使用其他支持无限滚动的表格组件吧，会发现诸多的问题：

  1.UI太丑，真的，特别是react-data-grid，不能再丑了。虽然它的功能很强大，但颜值是个硬伤。想给它整容，符合antd一惯的审美风格，还真的挺繁杂的，从上手到放弃系列。

  2.扩展起来，不接地气。有的组件库，功能很强，但封装得太厉害，说的就是上面的react-data-grid，还有react-tabulator，要想用起来，可不容易。说是react组件，可怎么用都觉得是反react，有点jq的倾向，惹不起。

  3.文档的可读性差。react-data-grid，react-virtualized好歹还有基础的API文档，虽然写的不咋地，但也比react-tabulator这个只能让人去看源码的强。

  4.版本不稳定。react-tabulator很任性，release直接从2,x升级到4.x...

  5.不支持树形表格编辑。说的是react-virtualized，或许新版本支持了，但不得不对它说抱歉。

  6.圈子不活跃，人少。人少、不活跃就意味着这个库可能不长久，比如react-tabulator。

一番比较下来，你会发现，还是react-component舒服，文档友好，扩展灵活，版本稳定，社区活跃，完全可以嵌套和插入自己写的react组件（就是丑了点），想必这也是antd基于它来做扩展的一个重要考量。antd或许是意识到了无限滚动地重要性，比如移动端的瀑布流，PC端商品列表的无限下拉刷新，在3.x版本已经基于react-data-grid做了一层扩展，增加了List组件，用来支持无限滚动。

但，对于表格而言，还是没有人性化的解决方案。

没办法，需求来了，不上也得上，自己手写一个吧。

目前为止，无限滚动没去做，只做了纵向虚拟滚动，滚动有些许延迟，但首次渲染和编辑的实时响应，还是可以接受的，而且支持固定左右列，横向滚动，完全支持自定义react组件的嵌套和插入，扩展起来太容易了。基本支持antd-table的用法。

实战

在动手写之前，要考虑一些问题：

  1.是采用原生table，还是用div来模拟？

  2.对于树形表格，采取怎样的虚拟滚动方案？

  3.组件的职责边界怎么界定？

一、原生table Vs div模拟表格

table之所以叫table，用意很明显了，在你想要以表格形式展示数据的时候，首先要想到的，就是用table。

table布局有浏览器的特定算法实现加速绘制，且对静态表格来说，页面结构是很稳定的。

虽然div模拟表格绘制的速度也不慢，但要达到跟静态表格一样的结构稳定性，可就做许多额外的维护工作了，css辅助，js控制，浏览器背后对table做的脏活累活，你基本都得接手，从零开始。

但table也有硬伤，首先是样式不好自定义，想改装原生table，让它变得好看，还真不是一件快活的事，具体参考antd-table。其次，如果要求表格左右列能固定，中间列可滚动，原生table就很绝望了，它不得不多叫来两个table兄弟，让他们来辅佐自己，一个在左，一个在右，跟自己装载同样多的数据，但却只显示固定列。三兄弟之间，还要时不时保持联络，确保大家每行高度都是一样的。

如果这中间出了什么偏差，就会导致滚动的表格看起来左边或右边的行像是掉了下来....用过antd-table的人，应该会有这样的体会。

而div模拟表格就不一样了，它是从零开始的，一张白纸，想怎么画就怎么画，要多美就能多美。

要实现左右固定列滚动也不必装载三份一模一样的数据，一份就够了，它要做的，仅仅是把列固定，将固定列邻居的位置计算好，就能达到同样的效果。

这里，想看示例，可以看看阿里这位大爷写的div模拟表格。

基于这个角度的比较，我得给div模拟表格投一票。

 

二、虚拟滚动方案

首先，得先理解虚拟滚动的概念。

滚动，相信大家都了解，无非就是块级盒子的内容长度或宽度超出了盒子的宽高，盒子若设置了溢出内容可滚动，那我们就会看到滚动条，可滚动的距离，跟溢出内容所占的长度或宽度是相等的。

 <div style="height:30px;overflow:scroll">
   <p  style="height: 10px">1</p>
   <p  style="height: 10px">2</p>
   <p  style="height: 10px">3</p>
   <p  style="height: 10px">4</p>
   <p  style="height: 10px">5</p>
   <p  style="height: 10px">6</p>
 </div>

 

如上述例子，4、5、6是溢出的。它们的高度是30px，即可滚动的距离。

可以预见，如果还有7、8、9…9999等等近一万条数据，那么这个div同一时刻，最多只能展示4条数据，剩下的9997条数据，都需要滚动才能看到。

创建一个dom节点，成本完全能接受，十个百个千个也可以接受，但上万数十万呢？就算能接受，也不该如此浪费。

既然只能在同一时刻看到4个节点，为什么不能只创建4个节点，剩下的节点都是通过滚动要展现的时候，才去创建呢？

这自然是可以的。

虚拟滚动，就是出于这个目的来设计的。

假设数据有6条，这里只讨论高度。

如果只创建4个节点，马上就会发现，滚动条能滚动的距离不对，只有10px。与预期的30px不符。这是因为，滚动距离是浏览器根据盒子和盒子里的节点的高度计算出来的。我们只能调整节点的高度，无法直接修改滚动距离的值。

我们可以通过在后面创建一个辅助节点，将高度设为20px来解决这个问题。

 <div style="height:30px;overflow:scroll">
   <p  style="height: 10px">1</p>
   <p  style="height: 10px">2</p>
   <p  style="height: 10px">3</p>
   <p  style="height: 10px">4</p>
   <p  style="height: 20px">占位符</p>
 </div>

 

现在，通过监听div的滚动事件，我们可以知道滚动条滚到了哪个位置，通过计算，得知展示的第一条数据在所有数据中，处于哪个位置，是第2条，还是第1条等等信息...

然后，进一步得知，哪一个未创建的节点，要立即被创建，并且，占位符的高度要对应变化。

例如上述例子里，展示2345的时候，占位符高度就要设为10px，并且最上面也要设置一个10px高的占位符，如：

 <div style="height:30px;overflow:scroll">
   <p  style="height: 10px">占位符</p>
   <p  style="height: 10px">2</p>
   <p  style="height: 10px">3</p>
   <p  style="height: 10px">4</p>
   <p  style="height: 10px">5</p>
   <p  style="height: 10px">占位符</p>
  </div>

 

遵循的原则就是，确保2345节点（我们称之为视图区）的高度，与占位符的高度加起来，等于总数据的实际总高度。

因此引申出的一个问题就是，每个节点的高度得固定（在表格里，就是固定表格行高）。或者，至少是在彻底展示完成之前，计算出实际高度。前面讨论过的组件库，除了react-data-grid，没有哪个不是固定行高的。

并且，视图区的高度也要指定。

如此一来，有了这些不变高度的数值，就能通过监听滚动来计算上下占位符各自的高度。

虚拟滚动的效果，也就达成了。剩下都是优化的工作，例如缓存节点，diff计算每次滚动时要改变的节点等等。

到这里，我们已经得出了扁平数据列表的虚拟滚动方案。

那么树形表格呢？

树形表格，准确的说，指的是数据在表格中以树形的形式来展现。这样的表格，可以展开/收起父节点，并且可以嵌套无限层级。参考antd-table的例子。

让树形表格支持虚拟滚动，可以利用刚才讨论的虚拟滚动方案。

这里的关键点在于，树形数据，是有父子层级关系的，并不是扁平数据。

因而首先要做的，就是把树形数据按顺序遍历平铺展开，即扁平化。

// 树形数据
const tree = [{
  node: 1,
  children: [{
    node: 11,
    children: []
  }, {
    node: 12,
    children: []
  }]
}, {
  node: 2,
  children: []
}, {
  node: 3,
  children: []
}]

// 树形数据按顺序平铺展开
const flatten = [{
  node: 1
}, {
  node: 11
}, {
  node: 12
}], {
  node: 2
}], {
  node: 3
}]]

如此一来，我们就可以完全复用讨论过的虚拟滚动方案，达成树形表格虚拟滚动的效果。

其次，树形表格的展现，一般是要根据层级的深度来缩进的，这样才美观。我们可以展开树形数据的时候，将层级深度记录下来，在创建节点的时候，根据层级深度来决定缩进的宽度。

这里，会遇到一些样式上的问题，比如展开图标、缩进的宽度，有可能会受到css规则的影响，使得实际效果与预期不符，这个就需要自己去排查解决了。

 

三、组件的职责边界

上面已经提到如何实现一个虚拟滚动的树形表格，但没提到树形表格怎么展开、收起子元素，更没提到表格的可编辑功能。

这涉及到组件职责边界的确定，也是现在要讨论的。

一个组件，特别是react组件，它应该有什么样的功能，能提供什么样的API以供扩展，是要考虑清楚的。考虑不清楚的，就像react-tabulator，写个自定义单元格编辑器都得寻找dom节点，跟JQ有什么区别，而且还要按照它们定的规则来写，否则就不起作用。

理想的组件，不应该附加额外的规则，而是利用现有的规则，加以合适的运行机制，来达到方便扩展的目的。

antd-table这点做的还算可以，我们只需要将自己的react组件跟提供的API对接，就能达成想要的效果。

所以，我们来确定一下虚拟滚动的树形表格，应该有怎样的职责边界。

首先，列出这表格该有的基础功能：

1.支持虚拟滚动

2.支持单元格自定义--任何dom节点或者react组件

3.支持左右列固定

没错，跟antd-table相比，只是多出了一个虚拟滚动。除此以外的其他功能，都应该是由表格的使用者来实现，诸如可编辑单元格，树形表格如何展开收起。

这些，可用一句话来总结——数据驱动视图。

如果用过D3，相信非常能理解这个理念。数据千变万化，组件的功能也能千变万化，这是很理想的状态。

这三个基础功能里，第1个可以采用上述的虚拟滚动方案来实现。第3个可以用css的sticky属性配合js计算来实现（具体不赘述，参考阿里大爷的例子）。

第2个，其实倒是最简单的了。

只需要用React编写每个单元格容器，就能做到支持单元格的自定义。因为react天生支持dom节点的嵌套，更是本身就支持react组件之间的互相组合。

到此，基于React手写一个虚拟滚动的表格，已经Over。

行动力强的读者，应该已经可以写出自己的demo了。

我写的表格例子，内部大概长这样：

      <Table onScroll={this.onScroll} style={{ maxHeight: this.tableHeight }}>
        <TableHead
          data={data}
          columns={dataColumns}
          rowWidth={this.rowWidth}
          rowKey={this.rowKey}
          onExpand={this.props.onExpand}
        />
        <Placeholder
          line={viewUpData.length}
          height={this.cellHeight * viewUpData.length + ‘px‘}
        />
        <ViewPort
          data={data}
          columns={dataColumns}
          rowWidth={this.rowWidth}
          rowKey={this.rowKey}
          onExpand={this.props.onExpand}
        />
        <Placeholder
          line={viewDownData.length}
          height={this.cellHeight * viewDownData.length + ‘px‘}
        />
      </Table>

外部使用虚拟滚动表格，大概是这样：

          <VirtualTable
            bordered
            expandedRowKeys={expandedKeys}
            rowKey="id"
            onExpand={(expanded, record) => { this.onExpand(expanded, record) }}
            dataSource={dataSource}
            pagination={false}
            scroll={{ y: 250 }}
            columns={columns}
            viewLine={7}
            onBeforeScroll={this.onBeforeScroll}
          />

如果之前使用了antd-table来实现功能，那么，只需要将antd-table换成虚拟滚动表格，再加个视图区的限定于滚动监听，就完全OK了，不用改变任何原有的业务逻辑。

 

后续

数据驱动视图理念的瓶颈，限于我的有限知识，认为应是在于海量数据频繁快速变化的时候，渲染视图的速度如何能跟上来，怎样做到让人觉得画面流畅，完全不卡。

比如100万条数据的下拉滚动。

 

学海无涯，苦作舟。这条路，一直是会有苦的...