這裡給大家分享我在網上總結出來的一些知識，希望對大家有所幫助

前言

Vue2 將在 2023 年年底停止維護了，但是 Vue2 的代碼卻不會在 2023 年消失，還會越來越多；難以想象幾十萬行或者幾百萬行的 Vue2 代碼遷移到 Vue3，這是不可能辦到的；

老一點的前端程式員肯定經歷過把大型項目從 jQuery 遷移到 Vue/React/Angular 的經歷，那是一次思想的大變革，也是生產效率的一次大革新，但是這一次就不一樣了，Vue2 遷移到 Vue3 雖然優點很多，但是這不足以說服老闆們花費$去讓你進行重構；

既然 Vue2 還能用，那我就想把他用到極致，日常中最常用的就是 Table 組件，所以 Table 組件出現屎山的概率大大增加了，再加上 UI 框架的加持，這個屎山就被放大了！Vue2 寫後臺也就是這幾個 UI 框架：Antd-vue、Element、iView,兩款是個人開發者出品，一款是餓了麽出品，來看看他們的 Table 組件

iView

iView Table 屎山

為什麼先說 iView，因為 iView 早期版本裡面的 Table 組件有一個很奇葩的設定那就是使用 render 函數來渲染 columns，而我們剛好用的 iView 版本就是這個時期的，後面也難以再升級，這個時候就產生大量屎山代碼了：

render:(h,{row})=>{
    return h('div',[
        h('a',{
            props:{
            
            },
            styles:{
            
            },
            on:{
                click:()=>{
                    
                }
            }
        },'新增'),
        h('a',{
            class:'xxx'
        },'修改'),
        h('a',{
            class:'xxx',
            on:{
                click:()=>{
                    Modal.confirm({
                        ...
                    })
                }
            }
        },'刪除'),
        h('a',{
            class:'xxx'
        },'配置'),
    ])
}

有沒有感覺到特別醜陋，而且寫起來效率也十分低下，好像回到了原始社會；原始社會裡面大家鑽木取火，現在一個打火機就能夠搞定，而這個 Table 裡面的 Column 的設定就像是鑽木取火了，一個 Colmun 還好，如果所有 Column 都這樣寫，並且都定義在 data 裡面，想象一下一個 data 都定義了幾百行，這是不是最大的屎山呢？

這個屎山有辦法破解嗎？答案是有的，總共有兩個方向，一個方向是編譯優化，一個方向是利用 scopedSlots

編譯優化

回憶一下 React，每一個 jsx 代碼其實都等同於 createElement("div",{},"xxxx")，與上面的代碼類似，那麼在 Vue 裡面也可以寫 jsx，然後編譯為 h 函數，按照這種思路上面的代碼就可以優化為：

render:(h,{row})=>{
    return <div>
        <a>新增</a>
        <a>修改</a>
        <a onClick={()=> this.onDelete(row)}>刪除</a>
        <a>配置</a>
    </div>
}

這樣的話看起來就舒服很多了，但是有人會說了：在 Vue 裡邊寫 jsx，又有 template 又有 jsx 搞得是四不像，不倫不類了，這種方式我不喜歡，還是想利用 Vue 的特性，要麼我就還是情願回到原始社會去鑽木取火；那麼下麵一種方式就是 scopedSlots

scopedSlots 優化

先說怎麼用：在 columns 數組中增加一個參數 slot，然後定義作用域插槽：

<template>
    <Table :columns="columns">
        <template #actions="{row,index}">
            <a>新增</a>
            <a>修改</a>
            <a @click="onDelete(row)"}>刪除</a>
            <a>配置</a>
        </template>
    </Table>
<template>
<script>
export default{
    data(){
        return {
            columns:[{
                title:'操作'，
                slot:'actions',
                key:'actions'
            ]}
    }
}
</script>

<td>
  <!-- 如果遍歷 colums 之後 slot 屬性存在，那麼渲染 slot，否則按照預設規則渲染 -->
  <slot v-if="slotName" :name="slotName" v-bind="{row,index}"/>
  <span v-else>...</span>
</td>

學會了這兩種優化方式，領導再也不用擔心我堆屎山了！

Element

再看看 Element 中的Table，舒服多了有沒有：

不用把 Column 的配置與 內容割裂開，可以都放在 template 中書寫，這樣比上面的方式靈活多了，而且還極大減少了屎山代碼的形成，對比下來還是 Element 的 Table 組件更為成熟好用；

antd-vue

最後一個是 antd-vue，看一下 antd-vue 中 Table 的用法，這不就和上面講到的 scopedSlots 優化那種用法類似嗎？

 翻到後面，可以看到一個 template 風格 API，與 Element 這種用法類似，但是後面緊接著提示：不推薦使用，會有一定的性能損耗。，為什麼會有性能損耗呢？那麼 Element 這麼用會有性能損耗嗎？

後記

到這裡 Vue2 中的 Table 屎山就結束了，再回頭看看 iView 直接暴露 h 函數，雖然極大地增加了 Column 定義的靈活度，但是增加了很多無效代碼就好像回到原始社會一樣，也增加了不少的屎山代碼；在日常開發過程中，很多需求都是趕著工期完成的或者倒排工期完成，根本沒有時間去思考怎麼優化，這個時候 UI 框架對於效率的影響就被放大了；好的 UI 框架不僅能夠提供好的交互效果，還能從 API 層面去約束開發者，讓開發者儘可能寫出好的代碼，另外就是讓開發者儘可能少寫代碼；

本文轉載於:

https://juejin.cn/post/7300151966964678668

如果對您有所幫助，歡迎您點個關註，我會定時更新技術文檔，大家一起討論學習，一起進步。