开源 UI 库中,唯一同时实现了大表格虚拟化和树表格的 Table 组件
背景
有这样一个需求,一位 React Suite(以下简称 rsuite)的用户,他需要一个 Table 组件能够像 Jira Portfolio 一样,支持树形数据,同时需要支持大数据渲染。 截止到目前(2019年1月18日)为止,开源 UI 库中没有找到可以支持的组件,所以 rsuite 在最新的版本中支持这一特性。
接下来,我们看一下 rsuite 中是怎么支持这两个功能?
大表格虚拟化
首先,我们看一下支持大数据渲染,在页面中渲染过多的 DOM 元素会带来性能问题,必须得有一种解决方案去优化它,我们暂且叫做大表格虚拟化。
所谓的大表格虚拟化,其实就是为表格设置一个较大的数据(比如 10000 条数据),然后虚拟一个表格隐藏掉不需要显示的数据。
为了解决让浏览器渲染的大量 DOM 时候出现的性能问题,我们不能把 10000 条数据都渲染到页面,采用一种方式,只渲染可视范围内数据。 同时为表格设置一个滚动条,只有在滚动到需要显示的区域时候才渲染该区域的数据,减少的 DOM 数量。
以上这是一个 10000 条数据的 Table,渲染后的 HTML 结构是:
我们可以看到在 Table 中只渲染了 14 个 rs-table-row
,其中第一个和最后一个是没有 children
, 只是一个拥有高度的占位符。 每一个 rs-table-row
都是绝对定位,所以即使 Table 中删除一个 Row, 或者新增一个 Row ,也不会改变其他 Row 的位置。 在这样的基础上,通过获取滚动条的滚动的位置,就很容易判断当前 Row 的 top 值是否在 Table 的可视范围内,同时更新所有的 Row。
很多优秀的库都实现了这样的功能,原理基本一致,比如 react-virtualized
就提供 Table 组件,但是他不支持 Tree。
树形表格
在表格中展示树形数据的需求,我们见得比较多就像甘特图表格展示那样。它有子父层级关系,可以展开子节点。
这样一个表格,很多 Table 组件都支持,但是如果同时需要支持虚拟化就相对比较麻烦,因为在展开关闭节点的时候需要重新计算显示的 DOM 以及设置滚动条的位置。
在 rsuite Table 组件之前的版本中,渲染的树形表格的 DOM 结构是一棵 Tree。 所以首先需要把 Tree 拍平,转换一个一维数组,为每一个节点设置父节点,通过父节点的深度渲染 Tree 节点的相对位置。 然后就比较好处理,只需要在点击展开关闭节点按钮的时候,处理好数据的过滤。
安装与使用
rsuite 的 Table 组件的设计,对开发还是非常方便,通过 <Table>
、<Column>
、<Cell>
、<HeaderCell>
组件定义结构,通过赋值data
属性渲染表格数据。
安装
npm install rsuite --save
如果你在项目只希望用到 Table, 不想安装整个 rsuite 库,你可以单独安装 rsuite-table
示例代码:
import { Table } from 'rsuite'; const { Column, HeaderCell, Cell } = Table; const data = [{ id: 1, name: 'foobar', email: 'foobar@xxx.com' }]; ReactDOM.render( <Table height={400} data={data}> <Column width={70} align="center" fixed> <HeaderCell>编号</HeaderCell> <Cell dataKey="id" /> </Column> <Column width={200} fixed> <HeaderCell>姓名</HeaderCell> <Cell dataKey="name" /> </Column> <Column width={200}> <HeaderCell>邮箱</HeaderCell> <Cell dataKey="email" /> </Column> </Table> );
最后
最后,对于一个成熟的 Table 组件怎么能只有这点功能,所以它还支持:
- 自定义调整列宽
- 锁定列
- 自动换行
- 排序
- 分页
- 编辑
- 合并单元格
- 自定义单元格
- 自动列宽
- 可展开行
剩下唯一的问题,就是您是否在项目中尝试它。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
浅析一次HTTP请求
一、概览 上一篇文章《对于Ping的过程,你真的了解吗?》我们通过抓包工具来分析了一次 Ping 的过程,我们知道了 ping 是依托于 ICMP 协议,然后再局域网中还会涉及到 ARP 请求,今天这篇文章我们同样用抓包分析工具来分析我们熟悉的 HTTP 请求是怎么样的? 二、环境准备 本来我是想找个网站进行抓包分析的,但是正式环境的网站 HTTP 请求太多,干扰太多,对分析不太友好,所以我简单些了一个demo,对 HTTP 请求返回字符串。 环境: 1.响应http请求的服务demo 2.客户端ip:192.168.2.135 3.服务端:45.76.105.92 4.抓包工具:Wireshark 我把demo部署到服务器,启动成功访问如下: 打开抓包工具 Wireshark 进行抓包,抓包结果如下: 图 Http-Request 从上图我们已经看到成功抓包到一次 HTTP 请求和响应了,但是我们看到却有很多TCP请求,接下来我们来分析下这些 TCP 请求是做什么的? 三、抓包分析 A) 三次握手 1.最开始是本地发送了2次请求到服务器,这里为什么会有两次请求,稍后再说,我们先主要看...
- 下一篇
百亿次的锤炼 - 地狱模式的分布式系统测试
本文以近期开源的Dragonboat多组Raft库为例,介绍Dragonboat这样一个典型分布式系统是如何做测试的。Dragonboat以Go实现,能在普通硬件上提供每秒1000万次以上的强一致读写,它是目前github.com上速度最快的功能完整的多组Raft开源库。欢迎大家试用,并请点Star支持:Dragonboat 最大的误导 常看到有系统吹捧自己可靠的方法是说某大型活动用了它,或说是某某公司某内部项目用了,从而得出可靠的结论,生产环境俨然成了廉价公关软文口中的测试平台。其实众所周知,某活动全场意外当机重启的节点数少之又少,磁盘毁损一整年才2-4%,而故障性的网络分区在很多DevOps岗的整个职业生涯里也就遇到几次而已,以至于多年来各一线公司网络分区造成故障的故事收集起来也才写满几页纸。某活动扛住了或是某项目用了,这些完全不是软件可靠与否的充要条件。 事实其实是残酷的。曾阅读过国内排名前四的某司一个共识库,30分钟代码读下来找到多处数据丢失毁损的bug,实现则是很典型的那种打死也不肯写测试的全裸奔模式。对于软件,任何无法用代码来验证的廉价营销式说辞,不说、不看、不听: 相较于...
相关文章
文章评论
共有0条评论来说两句吧...