前言

优化前

优化后

需求：

由于前面那个选择类型不同，下面的 el-table 渲染的数据也不一样。如图可以看到每行都有两个 el-select。

这里的 table 数据量整体是不大的，所以需求未做分页处理。虽然数据不大，但是 el-select 的每个里面都有 36个数据渲染的时候特别多的 el-option。导致页面卡顿的原因所在。

解决方案

虚拟列表

这个网上有许多 博客，大家也可以用用开源的项目包，引进项目中来。由于本项目的 项目总监说：项目要验收了尽量不要再引进开源的包，所以要么自己实现一个(太浪费时间了)

动态渲染 el-option

好在项目的 el-select 的 value 与 label 是对应的。所以可以使用本方案。

 this.tableDatas.forEach((item, index) => {
        this.$set(item, 'stakeList', [])
      })

给每一行都加上空的 el-option 的列表

  <el-select
    v-model="scope.row.logEndStartStr"
    placeholder="结束桩号"
    clearable
    style="width:100px"
    size="small"
    @visible-change="visibleChange(scope.row)"
    >
    <el-option
      v-for="item in scope.row.stakeList"
      :key="item.id"
      :label="item.dataLabel"
      :value="item.dataValue"
    />
  </el-select>

el-option 使用自己每行的 stakeList， 一开始是 空的列表，所以不会进行渲染。

当点击 el-select 触发了visible-change 函数。

 visibleChange(row) {
  row.stakeList = this.stakeList
 }

visibleChange 函数就把原先 36 的列表赋值，这样就生成的动态的渲染 el-option。

总结

至此优化就结束了，虽然代码的思路有点简单，但是这里只是是我第一次遇到可以使用虚拟列表来解决的方案，虚拟列表很早就知道这个，但是业务中从未遇到可以优化的地方。虽然这个优化没有使用到，但是也是一次不错的优化经历。