从 Issue 看 El-Table 源码，给 Element+ 提 Pr 的背后竟如此坎坷！

井柏然
3,334 阅读23分钟

Element Plus大家应该都不陌生，用过 el-table 的伙伴更是多数，毕竟搞ToB业务 table 必不可少，但是真正翻看过源码的应该还是少数，有没有对其内部实现怀揣着一点点好奇呢？笔者就是因为怀揣着好奇，所以才走上了源码这条不归路，为了让大家不走不归路，马上分享源码解析！现在回想当时，那是一个月黑风高的夜晚...

起因

故事的起因是这样的，在这个月黑风高的夜晚里，我手贱地点开了 Element Plus 的 gayhub，在上面翻看着各种内容，无意间，一条非常诡异的 issue 引起了我的注意，于是我就点开了，于是这就一发不可收拾了～

关于这条 issue 是这样的：

  • 使用 v-for 生成 <el-table-column /> 的 table ，添加 key 属性后无法改变 columns 的顺序。

el-table-demo.gif

这里笔者简要介绍下问题表象： image.png

如图所示，两个 table 都是通过 v-for 来完成 columns 的生成。

  • 其中第一个 table （黄色箭头）的 v-for 遵循使用规范，给循环的项增加了 key 属性。
  • 其中第二个 table （蓝色箭头）的循环中并没有添加 key 属性。
  • 有一个按钮，点击后会互换 columnsData 的 第一、第二条数据

现在笔者点击按钮后界面发生如下变化： image.png

对比这上面两张图，很明显就能看出来点击按钮后，没有绑定 key 属性的 table 成功互换了“两列”的位置，而加上了 key 的 table “表面上”并没有动静，还是维持了原本的顺序。

感兴趣的朋友可以通过在线调试（目前我的修复pr已经合并啦，需要切换到版本v2.2.28之前才能复现bug）： Playground 点进去自己玩一下～

好了，就是这么一个问题。不知道读到这里的朋友有没有在开发中遇到这样的问题呢？笔者自问了一下，为什么自己从来没有遇到这个问题呢？？？看来平时只要代码不规范，就不会有两行泪～此时此刻，我不由自主地掏出了下面这张图，原来图中的道理是真的，信不信由你！

走远了走远了，回到这个问题上来不妨先思考一下，对一个 v-for 列表的列表添加 key 本是最合理不过的事情了，为什么会导致 table 互换列失败呢？基于这一点的疑问，我们就要翻开它的源码了～当然，整个 table 的源码还是相对比较多的，而本文更多的是针对这个 issue ，以找到问题的根源为发起点去解析源码，不能尽善尽全还请多多见谅。

一、初识<el-table>

说起“初识”其实也不算“初识”，毕竟使用了这么久了，用这个组件来完成了很多业务需求，应该算是个最熟悉的陌生人吧！那现在我们就开始尝试更深入的了解这个老朋友吧。

1. 组成结构

虽然是看源码，但是一上来就堆代码就怕吓跑你们，这时候不妨先看看 el-table 完成渲染后是一个怎么样的 dom 结构组成。笔者就上面的 demo 截了个图如下： image.png 如图中圈起来的部分可以发现，整个 el-table 渲染到 dom 上面总体上分为两块：

  1. 表头部分。接着展开看看： image.png 不难发现，表头部分是由一个完整 table标签 + thead标签 等组成。
  2. 表格(body)部分。展开看看： image.png 跟上述表头的差不多，也是一个完整 table标签 + tbody标签 等组成的。

看完它们的表现形式后，我们真正的打开 table 的源码（位于：packages/components/table/src/table.vue），看看整体的组成是不是如我们所见的一样布局。由于整个 table 的模板代码已经去到差不多150行了，笔者删减了一些属性代码：

<!-- el-table 模板代码 -->
<div ref="tableWrapper">
  <div>
    <div ref="hiddenColumns" class="hidden-columns">
      <!-- 注意！！！发现一个默认插槽 -->
      <slot />
    </div>
    <div v-if="showHeader && tableLayout === 'fixed'" ref="headerWrapper">
      <!-- 出现第一个 table 标签 -->
      <table ref="tableHeader">
        <!-- 出现第一个 table-header 组件 -->
        <table-header ref="tableHeaderRef" />
      </table>
    </div>
    <div ref="bodyWrapper">
      <el-scrollbar>
        <!-- 出现第二个 table 标签 -->
        <table ref="tableBody" >
          <!-- 出现第二个 table-header 组件 -->
          <table-header
            v-if="showHeader && tableLayout === 'auto'"
            ref="tableHeaderRef"
          />
          <!-- 出现第一个 table-body 组件 -->
          <table-body />
        </table>
        ...
      </el-scrollbar>
    </div>
    <div v-if="showSummary" v-show="!isEmpty" ref="footerWrapper">
      <!-- table-footer 组件 -->
      <table-footer />
    </div>
    ... ...
</div>

尽管上述代码中，笔者删除了很多如 style 、 props 等属性，但是对 v-show 、 v-if 等决定组件显示隐藏的代码进行保留。这里笔者整理了一下对于排查 issue 需要多加注意的代码点：

  1. 默认插槽 <slot />。回顾一下 el-table 的用法，你就知道为什么要注意默认插槽。 
    <el-table>
  <el-table-column>这下你知道为什么默认插槽是需要我们注意的了吧</el-table-column>
</el-table>
  2. 第一个 table 标签。注意啦，这可是原生标签。从上述代码中可以看到，该 table 的显示条件是 showHeader && tableLayout === 'fixed'。这个我们一会说。
  3. table-header 组件。这个 vue组件 出现在 table 标签的包裹内容中，盲猜它最终渲染出来的结果就是 <thead> 、 <tr> 、 <th> 这几个原生标签！！！
  4. 第二个 table 标签。这个 table 标签即包裹了 table-header组件 、还包裹了 table-body组件 ！这阵势一看来头就不小。（注意这里的 table-header组件 也是有一个显示条件的）

好，总共就上面四点需要我们更加关注的，至于其他的嘛，说实话，笔者自己都没怎么看～话说回来，看源码的时候，最怕就是有一些长得几乎一模一样的代码块了，它们会影响到我们对主干代码的理解、会干扰我们的调试过程，所以首先需要我们排除异己！没错，说的就是上述中出现了两次的 table-header组件！当然你也会说 table 标签也出现了两次，但是其第一次出现就仅仅是包裹了个 table-header组件 而已，所以我们从table-header组件入手就可以了。

最最最简单的方式，当然就是通过它的文档，看看两个条件的显示关系啦。这里笔者先罗列出它们的显示条件，方便大家看出区别：

  • 第一个 table-header : v-if="showHeader && tableLayout === 'fixed'"
  • 第二个 table-header : v-if="showHeader && tableLayout === 'auto'"

翻查文档：

  1. showHeader 默认为 true： image.png
  2. tableLayout 默认为 'fixed'： image.png

根据文档的默认值表明，我们调试 demo 中的 table-header 为第一个，所以我们需要核心关注的源码大体结构是：

<div>
  <slot /> <!-- el-table-column 插入的地方 -->
  <table>
    <table-header /> <!-- 表头 thead -->
  </table>
  <table>
    <table-body /> <!-- 表格 tbody -->
  </table>
</div>

2. 了解 column、header、body 组件

大概了解了 el-table组件 的模板组成后，我们需要到具体每个其用到的vue组件内部，看看他们的内部组成是怎么样的，这样以方便我们对后续整个 table 的渲染流程有更好的理解。

注意，这里主要还是看结构为主，毕竟源码都是比较复杂的，会有很多分支处理细节，如果上来就直接闷头看源码很容易迷失～笔者习惯先从大体结构上看，然后调试主干代码，再根据自己的需要进入不同的分支代码调试，以此让自己对源码进行理解～

首先看table-column。这个算是这三个里头我们最熟悉的了，要杀熟！！！（源码位于 packages/components/table/src/table-column）。还是上面那句话，看大体！组件库嘛，可以从模板结构看起还是很舒服的。打开源码后发现其居然没有 template ，写的是 render函数，呵，没关系，难不倒我们～

// table-column 组件
render() {
  try {
    ...
    const vnode = h('div', children)
    return vnode
  } catch {
    return h('div', [])
  }
}

这么一看，table-column组件 直接返回了一个 div 的 vnode，好像并有没跟 table 的 dom 组成有啥关联，那是用来干啥的呢？这里我们先保留着疑问接着往下看。

接着看table-header。其模版代码也是直接写成了 render 的形式，代码比较多，笔者也就只保留我们需要关注的部分啦：

// table-header 组件
return h(
  // 哦豁，这不就是熟悉的 thead 标签的由来吗 
  'thead',
  // columnRows.map 会返回 <tr> 的 vnode
  columnRows.map((subColumns, rowIndex) =>
    h(
      'tr',
      // subColumns.map 会返回 <th> 的 vnode
      subColumns.map((column, cellIndex) => {
        return h(
          'th',
          // 这一层开始木有循环了，看来就是单个表头单元格的结构了
          [
            h(
              'div',
              {
                // 这个class="cell"熟悉了吧，不就是在dom上看到的放表头内容的地方吗
                class: ['cell'], 
              },
              /* --- 下面就是具体表头单元格内容的vnode了，可以不用关注 --- */
              [...]
            ),
          ]
        )
      })
    )
  )
)

来个小总结：

  • columnRows.map 作用看着是循环生成表头行的，有几项就返回几行 <tr>。为此笔者特地去找了个多行的表头验证想法（如下图所示）。照着样子看！猜想应该正确 image.png
  • subColumns.map 作用看着是循环生成单一单元格的（其中 subColumns 是 columnRows 循环的每一个单项）。那就是一行有几列就返回几个 <th>。

我们回顾整个 table-header 组件的 render 部分，并在 demo 上选中表头的其中一个单元格，可以发现 render 的结构跟最终的 dom 是完全对得上的。 image.png

最后看table-body。该组件也是只有 render函数 ，按照上面看两个组件的方式我们接着看。

// table-body 组件
render() {
  const { wrappedRowRender, store } = this
  const data = store.states.data.value || []
  // tbody 标签的 vnode 出处找到啦
  return h('tbody', {}, [
    data.reduce((acc: VNode[], row) => {
      return acc.concat(wrappedRowRender(row, acc.length))
    }, []),
  ])
}

好家伙，这么点？在当前文件的代码虽然是少了点，不过我们依然可以得到我们想要的信息。根据 render 的写法，可以清晰看到其 children 的位置（第三个参数）是 data.reduce 的返回结果，而其中调用了一个 wrappedRowRender 的方法，并且往里面传入了 row 的参数。于此，笔者总结一下：

  • data。data 一看就是整个 tbody 的核心数据部分，估计跟表格每个单元格的数据来源有密切关系。而其出处是：store.states，这意味着这个也是我们需要我们重点关注的。
  • wrappedRowRender。data 循环后啥事没干就调用它，估摸着跟整个表格内容的单元格渲染是有关系的！

好，到这里我们算是对整个 table 有一个初步的认识了，为了加深对它的认识，我们要马不停蹄的进入到下一个阶段，了解它的工作机制，一探其是如何渲染到dom上的！

二、<el-table>渲染

这一步，我们将通过更深入的源码阅读、源码调试的方式、探究 <el-table> 最终是如何渲染到 dom 上的。经过初识 el-table，在此我们只需要聚焦三个问题即可：

  1. 表头如何生成？
  2. 表格内容如何生成？
  3. el-table-column 看起来仅仅 render 了一个空 div，其作用是什么？

1. thead渲染

其实上文看 table-header组件 的 render函数 时，我们已经发现了整个 thead 的渲染无非就是循环了：columnRows，再循环了其每一个单项：subColumns。因此我们首先要搞明白 columnRows 是什么，怎么来的？

根据源码可以知道， columnRows 源自一个名为 useUtils 钩子的返回结果，该 hook 接收当前组件的 props 作为参数。下面是核心源码：

// useUtils
function useUtils<T>(props: TableHeaderProps<T>) {
  const columnRows = computed(() => {
    // 调用 convertToRows，并传入一个参数
    return convertToRows(props.store.states.originColumns.value)
  })
  
  return {
    columnRows,
  }
}

看到这里，我们明确接下来的两个点：

  1. props.store.states.originColumns 是什么？
  2. convertToRows 函数做什么？

首先我们得明确 props.store 里面到底装的啥？既然要找 props ，重新回到 table 组件，看看 store 是什么来头。在 table 组件的 setup 中找到了！并且不仅是 table-header组件、table-body、table-footer等组件都有传入这个 store ，看来属实重要啊！

// 拿到组件实例
const table = getCurrentInstance() as Table<Row>
/*
* 接收两个参数：
* table：当前 table组件 的实例
* props：组件 props
* */ 
const store = createStore<Row>(table, props)
// 把 store 挂在 table 上
table.store = store

而其中，createStore 函数里是通过 useStore 这个钩子函数来创建的 store，所以我们直接看 useStore 的源码（位于：packages/components/table/src/store/index.ts）：

function useStore<T>() {
  const instance = getCurrentInstance() as Table<T>
  // 关注 watcher，useStore 返回值的其中之一
  const watcher = useWatcher<T>()
  const ns = useNamespace('table')
  type StoreStates = typeof watcher.states
  // store状态变更处理
  const mutations = {
    setData(states: StoreStates, data: T[]) {
      ...
    },

    insertColumn(
      states: StoreStates,
      column: TableColumnCtx<T>,
      parent: TableColumnCtx<T>
    ) {
      ...
    },
    ...
  }
  // 提交状态变更
  const commit = function (name: keyof typeof mutations, ...args) {...}
  const updateTableScrollY = function () {...}
  return {
    ns,
    ...watcher,
    mutations,
    commit,
    updateTableScrollY,
  }
}

这么一看下来，useStore 像极了状态管理工具的那一套啊。我们完全可以理解成这是 table 组件维护的一个自己的状态管理。到了这一步，我们似乎已经初步了解到了 store 是什么东西，但是好像跟我们要寻找的 props.store.states.originColumns 好像还差了一点，所以我们把目光转移到 useWatcher 中，看看有没有我们需要找的跟 columns 相关的东西～

一点开 useWatcher (位于：packages/components/table/src/store/watcher.ts)，好家伙，差不多500行，我完全有理由相信里面有我需要的。直接看相关源码：

function useWatcher<T>() {
  // 定义 ref 数据 originColumns
  const originColumns: Ref<TableColumnCtx<T>[]> = ref([])
  
  // 方法是唯一对 originColumns.value 赋值的地方
  const updateColumns = () => {
    ...
    
    originColumns.value = []
      .concat(fixedColumns.value)
      .concat(notFixedColumns) // demo 中值的来源
      .concat(rightFixedColumns.value)
    
    ...
  }
  // 导出的对象最终会在上述的 useStore 中原样导出（return { ...watcher }）
  return {
    updateColumns,
    states: {
      originColumns,
      columns,
    }
  }
}

到这里，我们成功找到了 props.store.states.originColumns ，并且知道其在 updateColumns 这个方法中进行赋值。这时笔者对 demo 进行 debugger 以追寻值的来源，发现值源于 notFixedColumns，于是顺着找上去，找到了 _column 这个变量，如图所示： image.png

最后一步！ _column 值的是怎么来的，笔者在 store 的 mutations 中找到了线索。其中一个为 insertColumn 的 mutations，里面有对 _columns 进行赋值的操作。

// store 的 mutations 中的一个方法
insertColumn(
  states: StoreStates,
  column: TableColumnCtx<T>,
  parent: TableColumnCtx<T>
) {
  // 取到 ref states._columns 的值（可简单理解成 states._columns.value）
  const array = unref(states._columns)
  let newColumns = []
  if (!parent) {
    array.push(column) // 插入 column 值
    newColumns = array
  } 
  sortColumn(newColumns)
  states._columns.value = newColumns // 将值赋给 _columns
  ...
}

这玩意从哪里开始调用的？笔者顺着调试的调用栈往上翻，好家伙，找到一个我们很熟悉的地方去了： image.png 这不正是差点被我们遗忘掉的 table-columns 组件的 onMounted 钩子里执行的吗？？？还记得上面看这玩意的 render 只搞了个空 div 吗？差点就以为没这货啥事了，原来它就是主宰了 store 里 columns 来源的神啊！

再回过头去扫一眼 table-column组件，不难发现整个 column对象 就在其 onBeforeMount 中进行定义（包含了很多的属性）；再在 onMounted 阶段 commit 了 insertColumn 的修改函数实现了 store 中 columns 相关的数据新增。

onBeforeMount(() => {
  const defaults = {
    ... // 很多 column 的属性
  }

  const basicProps = [
    'columnKey', ...
  ]
  const sortProps = ['sortMethod', 'sortBy', 'sortOrders']
  const selectProps = ['selectable', 'reserveSelection']
  const filterProps = [
    'filterMethod', ...
  ]
  // 返回一个 将上面的数组字符串都转化成对象key 的对象 
  let column = getPropsData(basicProps, sortProps, selectProps, filterProps)
  // 跟 default 进行属性合并
  column = mergeOptions(defaults, column)
  // 最后赋值到 columnConfig.value
  columnConfig.value = column
})
onMounted(() => {
  // commite 'insertColumn' 的 mutation 实现 store 中的 columns 设置
  columnIndex > -1 &&
    owner.value.store.commit(
      'insertColumn',
      columnConfig.value, // onBeforeMount 中赋值的
      isSubColumn.value ? parent.columnConfig.value : null
    )
})

这样一来，我们已经找到了数据的源头，只需要再了解处理 columns 的函数 convertToRows 就能揭秘整个 thead 的渲染流程了，毕竟整个 render函数 都是围 columnRows 展开的！接着往下看👇🏻

接着看 convertToRows，首先看看源码实现：

const convertToRows = <T>(
  originColumns: TableColumnCtx<T>[]
): TableColumnCtx<T>[] => {
  let maxLevel = 1 // 代表n级表头，demo中是1
  const traverse = (column: TableColumnCtx<T>, parent: TableColumnCtx<T>) => {
    // 处理表格列横跨多少的，colSpan，无需重点关注。
    ...
  }

  originColumns.forEach((column) => {
    column.level = 1
    // 表头横跨处理（详细了解可看多级表头的案例），demo 中的 colSpan 都是1
    traverse(column, undefined) 
  })

  const rows = [] // n级表格就有 n 行，demo中是1
  for (let i = 0; i < maxLevel; i++) {
    rows.push([])
  }
  // 获取所有列（处理嵌套表头），在demo中返回值就是 originColumns 的数组
  const allColumns: TableColumnCtx<T>[] = getAllColumns(originColumns)
  // 给每一 行 添加 列 ，demo中只有一个row，所以可以很好理解成就是 originColumns 的数组
  allColumns.forEach((column) => {
    if (!column.children) {
      column.rowSpan = maxLevel - column.level + 1
    } else {
      column.rowSpan = 1
      column.children.forEach((col) => (col.isSubColumn = true))
    }
    rows[column.level - 1].push(column)
  })

  return rows
}

最后，笔者在 table-header 的渲染函数中打上 debugger 来验证一下，没有意外，就是那个 column对象！等 render 执行完成后得到 vnode ，再经过 patch 就实现 thead 的渲染啦，就是那套熟悉的 vue 组件化流程！ image.png

解析到这，我们就很清楚的知道 thead 的渲染流程了。笔者甚至花了大半的篇幅在讲述寻找数据源的历程，因为那才是整个 table 渲染的核心地方。在这里，笔者画个图回顾一下整个 thead 的渲染流程，了解完细节后再抛开细节看整体，也许会有更加清晰的理解： el-thead渲染.png

2. tbody渲染

先回忆一下上文提到的 table-body 的渲染函数，印象中似乎就没几行代码！ image.png

所以整个小节我们的目标很明确，只要破解 wrappedRowRender 这个关键点和找到数据源 data ，就能还原整个 tbody 的渲染流程了！当然这里寻找数据源就没有像寻找 columns 的那样隐晦了，因为我们是显示的往 el-table 中传入一个 data 属性的。

数据源 data。其实就是我们给 table 传入的 data。这里笔者不会再展开大篇幅赘述，因为都比较好理解，所以就简单带过一下：

  • 早在 table组件 createStore阶段，就已经通过 proxyTableProps 给 states.data 赋值了
  • 经过 debuger 会发现后续也会有 setData 的 mutation 给其赋值

so，结论就是，整个数据源 data 就是跟我们传入给 table 的无差的，其中可能 table 自己对其做了一些处理，如做了层 proxy 监测等，这都不影响我们对 data 的理解，反正就是我们传给 table 的 data。

wrappedRowRender 函数（源码位于 packages/components/table/src/table-body/render-helper.ts）。首先看看函数实现：

const wrappedRowRender = (row: T, $index: number) => {
  const store = props.store
  const { isRowExpanded, assertRowKey } = store
  const { treeData, lazyTreeNodeMap, childrenColumnName, rowKey } =
    store.states
  const columns = store.states.columns.value
  const hasExpandColumn = columns.some(({ type }) => type === 'expand')
  if (hasExpandColumn) {
    ...
  } else if (Object.keys(treeData.value).length) {
    ...
  } else {
    // demo 代码会走到这一步
    return rowRender(row, $index, undefined)
  }
}

总的来说，整个 wrappedRowRender 就是对 常规 、 展开行 、 树形 表格的 vnode 进行返回。demo 代码属于常规表格，所以我们需要关注 rowRender 的函数实现：

const rowRender = (
  row: T,
  $index: number,
  treeRowData?: TreeNode,
  expanded = false
) => {
  const { tooltipEffect, store } = props
  // 在 store 中拿到 columns，columns 其实跟上述 originColumns 是在同一个地方赋值的
  const { indent, columns } = store.states
  ...
  // 找到 tbody 的 render 啦
  return h(
    'tr',
    {...},
    // 循环每一列
    columns.value.map((column, cellIndex) => {
      // tdChildren 是需要渲染内容的 vnode（根据 data 和 column 配置生成）
      const tdChildren = cellChildren(cellIndex, column, data)
      ...
      return h(
        'td',
        {...},
        [tdChildren]
      )
    })
  )
}

源码看到这里，再加上经历过长篇大论的 thead 渲染的熏陶，相信这里已经对 tbody 的渲染有一定掌握了。其实整个的渲染并不难，就是一个二维数组的循环，然后执行对应的 render 函数生成 vnode，接下来一就是熟悉的 vue 组件化流程。笔者简单总结 tbody 渲染的两点：

  1. 循环 data 数据，得到每一“行”的数据
  2. 在每一项 data 的循环中循环“列”，生成每一列（这里就是单元格了）的 vnode

三、定位问题

这一节将是本文的重点！跟大家一起破案啦！！在简单掌握了 el-table 的渲染原理之后，我们就可以开始分析问题的原因在哪里了。长篇大论了一堆，大家可能都忘记 issue 这件事了～ 回顾一下问题：

  • v-for 生成的 column 绑定上 key 后无法更改 column 的顺序。

1. 为什么 key 导致 columns 换位失败？

在没有阅读过 table 源码的时候，你可能会猜测是不是 vue 的 diff 出问题啦；还是说数据改变因为 key 没有触发组件更新等等...但是当你了解了 el-table 的基本实现之后你会发现：最终呈现出来的组件成品，压根就没有以 column 为单位的 dom 元素。这么说不清楚，笔者还是接着画图吧～

你以为你 v-for 的 columns 是这样的：

table-columns.png

但其实最终是这样的：

table.png

所以，根本就不存在以列为单位的元素，只有以 tr 为行，td 为行中每一项的单元格。即使是互换列，也不可能是简单的互换两列，只能是第一行的两两单元格互换，第二行的两两单元格互换、第三行、第四行...说到这里，你可能大概能理解这个 issue 为什么会存在了。

基于此，笔者进行一个猜测：其实当我们改变列数据的顺序时，“真正”的 table-column 的顺序是改变了的，只是表格没有变化。大家可能不知道什么是 “真正”的 table-column ，此时我们回忆一下 column组件 的 render函数，生成的是一个空 div 的 vnode。既然是这样，不如做个实验验证一下！

首先找到 dom 的位置。回忆 table 组件的组成结构，默认插槽放在一个类名为 hidden-columns 的 div元素 内(方便标识，笔者搞了个 class 为 ccc-${index})。并且为了让大家能看得清变化的效果，笔者直接在浏览器上编辑这2个dom元素，给他们加入内容： image.png

接下来，笔者点击按钮以互换两列顺序，效果如下： el-table-key.gif 基于这种表象印证了之前的猜想，表格的内容虽然没有改变，但真正由 el-table-column 渲染出来的 div 其实是成功互换位置的，只是因为其是隐藏的我们表面上看不出来而已。

事已至此，我们思考一下为什么 key 导致 table 换位失败？（ps：没办法啊没办法啊，搞个 table 被迫去看 Vue3 源码）

  1. 首先是组件更新问题。互换列时修改的响应式数据并没有直接在 table-header 、table-body 组件中使用，然后 table-column 组件又命中了 diff 的逻辑，所以当修改数据触发组件更新时这三个组件都不会重新执行 render ，而是复用之前的 vnode 去 patch。所以：不重新 render，何来更改顺序后的新 vnode 呢？
  2. 其次是 store数据变更 问题。回忆 el-table渲染 章节，整个 table 的渲染都依赖 store 中的 columns 数据。而我们修改数据触发 table-column 组件重 render，但仅仅在 render 阶段是不会对 store 数据进行改动的，所以此时 store 中的 columns 顺序依旧不变（回忆 columns 的数据一开始是在 mounted 阶段 insert 的）。

既然明确了传入 key 带来的表象的原因，那现在又出现了另外一个问题：为什么不加 key 就可以按照用户预期进行表格的列互换？接着我们往下看。

2. 为什么不加 key 就能互换？

当然，到了这一步，盲猜都知道是触发整个 table 的重渲染了，table-column 、 table-header 、table-body 三者都重新 render 了一遍。盲猜归盲猜，但总得找出真的根源来分享给大家啊是吧，于是......于是又掉进了一个漩涡，深不见底！听笔者娓娓道来。（注意！由于代码复杂度问题，在调试这个案例的时候笔者仅以 table-header 的组件为调试例子，因为只要从 table-header 中可以得出结论的话，那 table-body 也是同理！）

要想搞明白这一点，不去看 Vue3 源码是不行的了，因为 Vue3 很多地方都跟 Vue2 不同，再以 Vue2 来理解和解释问题已经很难走下去了。当然，这里不会展开太多，因为跟主题不相关了，所以笔者会直接给结论。详细了解可自行查看 vue3 patch流程源码 和 diff的源码 哈～

  1. v-for 中加 key 和不加 key 区别？

    • 有key：patchKeyedChildren。逻辑比较复杂，里面是分了5个步骤的 diff 逻辑，最终会执行到 patch。
    • 无key：patchUnkeyedChildren。逻辑比较简单（总共就20行代码），直接 patch 。 image.png

  2. 两个 patch 之间有什么区别？表象就是参数不同。

    • 有key：经过一轮的 diff 算法的洗礼，传入 patch 的参数是相同的 table-column，它们只是在新旧的 list 中顺序不同。
    • 无key：patch 参数：(旧vnode[0], 新vnode[0])，然后就直接开始 patch 流程了，会走一趟完整的组件更新流程。

  3. 两种参数下会导致 patch 结果有什么区别？

    • 有key：最终 patch 的结果是复用 vnode ，所有组件（column、header、body）都不会 rerender（因为 update 中有个 shouldUpdateComponent 的判断，感兴趣自己去看看，还是比较有意思的）
    • 无key：组件更新，然后会重新赋值 props 值！！！。感兴趣的可以自行去仔细阅读 updateComponentPreRender 中的逻辑，其中有 updateProps 的处理。 image.png 没错，如图所示，无 key 的情况下会在这个位置对 props 进行重新赋值。区别就在这里了，这一点也是最重要的！

以上就是 Vue 部分的源码调试结论。大家千万不要觉得结论就几句话很简单，这可是笔者通宵达旦+1 +1 +1...给 debug 出来的。而且为了找到这个点，笔者正向 debug 了很久无果，在进行了无数次的反推才定位到的。只能说要调试 Vue 组件化、渲染这一块逻辑的话，真的太多太多了。好了扯远了，简单交代了有无 key 在 Vue 部分的区别后，我们回到 ElementPlus 的代码中，再接续听笔者娓娓道来～

上面已经提到 props 的更新，所以很明显无 key 状态下能触发 table 按照用户预期的渲染，当然跟这个 props 有不可分割的关系，这个时候我们也离真相很近了！还记得笔者在第二节 el-table渲染 中提到过数据源 store.state 这玩意吧，笔者有提到在 table-column 组件 onMounted 阶段对 state 中的 columns 进行 “insert” 的这么一步。

这里我们仔细看看 table-column组件 具体的数据定义和实现（注意啦，columnConfig 是个 ref 的对象）：

// columnConfig 是一个定义成 ref 的对象
const columnConfig = ref<Partial<TableColumnCtx<DefaultRow>>>({})

onMounted(() => {
  // commite 'insertColumn' 的 mutation 实现 store 中的 columns 设置
  columnIndex > -1 &&
    owner.value.store.commit(
      'insertColumn',
      columnConfig.value, // 这里我们注意传进去的是一个引用
      isSubColumn.value ? parent.columnConfig.value : null
    )
})

再认真看看 insertColumn 这个 mutation，主要关注其 push 参数 column 这一步：

// 这个 _columns 也是一个 ref 数据
insertColumn(
  states: StoreStates,
  column: TableColumnCtx<T>, // 注意这里的参数是上面的 columnConfig.value
  parent: TableColumnCtx<T>
) {
  // states._columns 本就是一个 ref 数据
  const array = unref(states._columns)
  let newColumns = []
  if (!parent) {
    // 这里push进去的，是一个 ref 的对象！！！
    array.push(column)
    newColumns = array
  } 
  sortColumn(newColumns)
  states._columns.value = newColumns // 将值赋给 _columns
  ...
}

最后再给大家看看一大堆的 state 的响应式数据定义： image.png

好了，上面讲这些什么响应式数据啊、对象的引用啊不为别的，只为了明确一个点：只要table-columns 组件的 columnConfig.value（再次强调其是个对象！） 的属性值改变了，就能触发 table-header组件 的重新渲染，因为这个组件接收了 store 这个 props。伟大的Vue响应式系统，让我找这个数据变化找的好苦啊...

接下来是破案的最后一环。既然上面分析 vue 源码在处理 有 key 和 无 key 时候的核心区别是 rerender 和 对 props 进行重新赋值，那我们就来看看是哪个该死的 props 变化触发了 table-header 组件的更新。这个好办！反正 demo 中又没有几个 props 🤪： image.png

最后，笔者在 table-column组件 中发现了 registerNormalWatchers ！这是在该组件的 setup 中执行的一个方法，用于观测 props 变化，具体我们往下看。其中里面的实现是这样的：

const props = [
  'label', // 其实案例中就是 label 的值发生改变
  ...
]

Object.keys().forEach((key) => {
  const columnKey = aliases[key]
  if (hasOwn(props_, columnKey)) {
    watch(
      () => props_[columnKey],
      (newVal) => {
        // 看到没！！！columnConfig.value 的引用值改变了
        instance.columnConfig.value[key] = newVal
      }
    )
  }
})

不难发现，这个 watch 就是对一些 table-column组件 中的 props 进行监听，然后将变化的值同步到 columnConfig.value 中，其实也就是同步到整个 table 的数据源 store 中。然后在本次的调试 demo 中，其实就是 lable 改变了，大家可以回看 vue 源码调试截图，笔者特地截下了 label 被重新赋值的断点状态～

结论：由于 props.label 数据变更，必然造成 columnRows（上文提及渲染表头的关键数据源） 中的 label 属性更新（同一个引用），又因为数据变化触发了 header组件 的 rerender（根据最新的 columnRows 重新生成表头 vnode），所以表头互换位置成功！

分析完 为什么没有 key 的时候能触发 table-header 的 rerender 和最后成功互换两列的情况后，同理也可以推断出 table-body 也是受到这种原因的影响，不管是不是由于 label 的变化而引起的。反正现在可以很明确的一点是：因为有响应式数据改变所导致其 rerender ，所以互换列成功了。

ok！这下终于破案了，完全可以解释为什么不加 key 的时候就能使 table 按预期渲染。感觉自己能写到这里可真不容易啊，调试到人麻了～当然，能看到这里的伙伴也很不容易，毕竟好一大篇的内容呢哈哈哈。

写在最后

好啦，在最后其实笔者也想分享一下代码的调试心得，毕竟这种跟组件化、渲染相关的问题多多少少都得跟所依赖的 js框架 搭边，不能单凭对 ui库 调试就能得出结论的。所以如果要对 js框架 进行调试，那必定是一个很复杂的场景，所以 demo 一定要最简化！笔者自己调试的时候，几乎把整个 el-table 都删干净了，就留下了 slot 和 table-header 来调试，但还是耗费了很多时间。然后有时候也要进行一些适当性的反推，说不定能有妙用！

该说不说整个 el-table 的源码是很多也比较复杂的，源码阅读加调试确实很麻烦。另外呢，像这种问题一般很少人会究其原因，因为不加 key 就能解决问题，相比之下究其原因的成本就显得非常巨大。但是笔者发现这类 issue 不止一个（随便翻都找到2个相关的），所以肯定是有部分开发者会遇到这个问题，一旦要排查说不定就是大半天的时间，而且业内、开发者内部似乎也没有对这个问题进行说明，最多就告诉你是 key 导致的，所以笔者觉得还是有必要深究一下～

如果你觉得看完有所收获！不如给我个一键三连吧！我们一起进步。

本文正在参加「金石计划 . 瓜分6万现金大奖」

avatar
文章
阅读
粉丝