关于element的table优化问题
来源：2-2 安装 Typescript 文档
有没有没被占用的昵称
2022-02-09
老师，我最近在做一个功能，需求大致是这样的
1.后端同事返回给我一整个数据表的字段，不分页，可能有上百条记录。
2.数据格式如下图，除了fieldCode字段名之外，其他字段用户都可以进行编辑。
于是，页面就变成了这样，字段的取值包含了单选、多选、级联、switch还有input
接下来给老师诉说一下我的的优化之路
1.最开始是直接全部渲染出来，这个时候性能问题非常明显，比如说点选一个checkbox，select点击选中一个选项，都要经过几秒钟的事件页面才会响应结果。
我通过观察performance，主要的时间是花在了scriping上，加上自己调试，基本上得出结论是element的table的渲染问题。
2.第二次我选择了通过下拉渲染的策略，但是问题又出现了，起初用户没有向下滑动，table的数据可能只有十几条，性能方面不存在明显问题，但是到滚动条滑动到底部，数据全部都渲染完了，问题就又出现了。
3.第三次我选择了通过proxy来代理整个list，从而实现一个虚拟分页，性能有了很大的改观，但是其实反应慢半拍可以察觉的出来的。
请问老师，这个问题我应该怎样解决呀。
我们的table组件是在element的基础上扩展的，代码基本一致
我自己通过文章（https://juejin.cn/post/7007252464726458399）进行了优化
主要模仿了他的更新渲染优化，但是性能提升看不太出来
接下来他的v-memo缓存策略的话，他是判断某一个row是否选中改变，但是我的row基本上每个字段都可能改变，不可能一个个去比对，所以这个策略应该不适合我当前的业务场景。
所以老师，还有什么办法呀
1回答
-
同学你好
由于没有特别多的时间去直接看代码和运行 我简单说一下
这个是一个标准的大表格的问题，原因就是 element-table 的性能问题（其实也不算，因为 element-table 就不是为大表格所设计的），我觉得你的调试过程已经很清晰的表明了你的思路了。
我的解决方案：
1 换成分页渲染，不要一次全部渲染，不要下拉加载。
2 使用支持 virtualized 的表格，这是一个渲染大数据的时候的常用做法，只渲染目前在可见的数据，react 的实现，https://bvaughn.github.io/react-virtualized/#/components/List
element-plus 目前没有 virtualized-table，但是它在开发中，已经有了 virtulized-select，https://element-plus.gitee.io/zh-CN/component/select-v2.html 以后应该会有对应的 table 组件。
ant-design-vue 有类似的实现：https://2x.antdv.com/components/table#components-table-demo-big-data
它底层使用的是 surely vue，可以尝试一下：https://www.surely.cool/
042022-02-10
相似问题