背景
因公司项目需要一个非常复杂并且性能要求的虚拟表格，并且在途中因为早期没有预先设计好和中途不断修改，导致后期的优化变得非常困难，所以在这里总结一下这次复杂虚拟表格优化的点和总结。
总结这次可以优化的点
- 没有对选择的虚拟表格库进行充分的 demo 测试，导致一些根本不需要的操作和性能消耗。
- 没有预先对表格整体功能进行设计，导致中途不断改动，让功能越改越乱。
- 对于功能区分和抽象做的不够好，有的功能是可以复用的，但是因为没有抽象出来，导致功能混杂。
没有进行充分的 demo 测试
对于一个新的库，我们需要对其进行充分的 demo 测试，这样才能对其进行更好的评估，而不是一上来就直接上手，这样会导致一些根本不需要的操作和性能消耗。
- 本次的
ag-grid的自定义单元格，对于某个数据的更改之后以及回显都通过了一些比较复杂的手段进行更新和显示 - 还有就是在不同模式下的列固定，不需要更新整列单元格，只需要更新固定列的单元格即可
- 定义筛选列的时候，可以通过
filter自定义筛选组件来进行筛选，而最终实现是通过pinia store里定义搜索条件和监听变更，然后使用自定义表头筛入筛选功能 - 单元格悬浮和获取焦点之后的全局
popover，单元格和popover之间的联动 - 还有自定义联动更改，在单元格变更之后同步其他单元格里的值更新没有做到最细粒度更新
- 在最开始的时候没有定义
ag-grid的getId，导致ag-grid无法对单元格进行复用，导致每次滚动都会重新渲染所有单元格 - 早期为了确保数据和列显示永远是最新的，不得已用
key强刷表格导致滚动条回弹到顶部和侧部 - 表格单元格数据验证问题，应该由统一的校验方式入口进入并且表格单元格标红不应该以行数来作为索引，而是应该以统一标识+字段名来作为索引
- 数据量太大的时候没有用 webworker 进行数据处理，导致存在大数据量页面卡顿
- 还有一系列小问题
没有预先对表格整体功能进行设计
- 表格筛选之后的行合并，因为一个合并可能会有100、1000、10000行，并且筛选之后的合并也需要改变
- 每个单元格触发的
popover可以以异步组件载入然后通过统一标识+字段名作为key去区分，并且触发方式都是统一的 - 表格的向下填充功能没有进行充分的设计和预留可扩展，导致后期发现筛选之后向下填充功能数据紊乱
- 没有组织好各个组件之间的关系，导致后期不断的改动，导致原本小而美的组件变得大而丑
功能区分和抽象做的不够好
- 对于表格内部数据在开始的时候组合和后期的数据变动覆盖，一开始是写在
pinia store里，并且合并功能也是放在一个函数里，导致后面维护非常麻烦，抽离之后只需要维护不同功能的函数即可 - 对于表格数据验证的设计和抽象，表格触发验证的时候有 3 个情况，分别是
单元格被改变、使用向下填充功能、数据整体校验，然后每个情况在不同的逻辑下要允许跳过为空，但是有时候又不能跳过，以及每个情况下传入参数不一样，所以要针对不同的情况做函数抽离或者参数抽离，这样才能保证代码的可维护性 - 对于数据的向下填充，要在不同的列下要有不同的触发方案，并且要考虑到单元格变更也算是一个填充自己的行为，所以也要抽离整合，区分之后预留可扩展性，并且还要考虑到筛选之后的填充情况，以及不同行之间的联动情况
- 对于单元格的禁止和只读，还有格式化显示，都集中在了一个组件内部，实际上可以通过表格自带的参数和我们自定义的 hook 组合起来实现，这样可以减少组件的复杂度，也可以减少组件的渲染次数
总结
对于这次的复杂虚拟表格优化，其实也是对于自己的一些不足的总结，希望以后在做类似的项目的时候能够更加的注意这些问题，避免再次犯错。
参考
针对部分情况进行了优化，让代码看起来更直观和更美观以及更好的性能
项目代码可以参考 这里