Element 表格多选性能优化

起因

公司的基础组件库是基于 ElementUI 进行二次封装的,某天有个前端跟我反映表格组件渲染 500 条数据的情况下,多选功能的全选会变得特别卡,点一下要卡 10 几秒,我一想应该不至于啊,500 条数据量也不是特别大,怎么会卡这么久呢,会不会是他业务逻辑写得有问题,后来一测试,发现当表格的列数比较多而且结构比较复杂时,确实会让全选功能变得特别卡,那么接下来就调试分析下原因。

问题排查

Performance 分析

对于这种 js 脚本运行时间过长的问题,最好的排查方式就是利用谷歌开发者工具的 Performance 来进行排查。

打开 Performance,点击 start 开始记录,然后在表格上点击全选,等到全选效果渲染完毕,点击 stop 停止记录。

1.png

可以发现 js 脚本的大部分时间都用于执行 render 方法,而该方法就是 table-row 组件的 render 方法。

深入代码

table-row 组件用于渲染表格整一行的结构,导致 table-row 组件重新渲染的原因是组件 props 上的 isSelected 的值发生了改变。

2.png

isSelected 的值是在 table-body 组件的 rowRender 方法中通过 this.store.isSelected(row) 来确定的。

3.png

由于这个方法在内部访问了 states.selection 这个响应式属性,从而导致了依赖的收集,换而言之,只要 selection 发生了变化,就会触发 table-body 组件的重新渲染。

4.png

由于我们点击的是全选,所以可想而知重新渲染的时候所有 table-row 组件的 isSelected 属性都会发生变化,最终全部都会进行重新渲染,当表格的每一行内容比较复杂的时候,table-row 组件 render 的时间就会比较长,在行数比较多的情况下就会出现卡顿的现象。

优化方案

既然我们点击的是勾选功能,那为什么整个 table-row 组件需要重新渲染呢?能不能只重新渲染 table-row 组件内的 checkbox 组件呢?顺这个思路,就得到了一个优化方案。

因为 vue 的更新颗粒度是组件,所以可以将原先的 checkbox 封装在一个新的 table-checkbox 组件中,然后 isSelected 的值不再由父组件层层传递下来,而是在这个组件中直接通过 store.isSelected(row) 直接访问,这样之后 selection 引起的更新就只会通知到这个新的 table-checkbox 组件重新渲染了。

5.png

再谈一谈为什么 Element 不这么优化,ElementisSelected 的值在 table-body 组件的 render 中确定好,然后再一层一层传下来,这样当只有一行的选中状态改变时,就只会更新一个 table-row 组件,但如果采用我们这种优化方式,就算只有一行的选中状态改变了,只要 selection 变化了就会导致所有的 table-checkbox 组件更新,所以对于全选来说这种优化方法是有效的,但对于单选来说可能会比原来性能变差一点。

由于当前我们项目确实遇到了全选卡顿的问题需要解决,而 table-checkbox 组件本身比较小,所以就算单选更新所有组件也不会造成明显卡顿,所以综合考虑之后还是采用了这种优化方案。

代码地址

github.com/DLillard0/e…

© 版权声明
THE END
喜欢就支持一下吧
点赞0

Warning: mysqli_query(): (HY000/3): Error writing file '/tmp/MYuH1qev' (Errcode: 28 - No space left on device) in /www/wwwroot/583.cn/wp-includes/class-wpdb.php on line 2345
admin的头像-五八三
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

图形验证码
取消
昵称代码图片