拒绝！封装el-table，请别再用JSON数组来配置列了
阅读本文📖
你将：
- 明白通过
JSON来配置el-table的列可能并不是那么美。（作者主观意见） - 学会一点关于VNode操作的实例。（一点点）
- 辩证地思考一下当我们在团队内对组件进行二次封装时，哪些东西是我们需要取舍的。
前言
大家好，我是春哥。
我热爱 vue.js , ElementUI , Element Plus 相关技术栈，我的目标是给大家分享最实用、最有用的知识点，希望大家都可以早早下班，并可以飞速完成工作，淡定摸鱼🐟。
相信使用 vue 的同学大部分都用过 Element 系列框架，并且绝大部分都用过其中的 el-table 组件。并且几乎所有人都会把表格和分页进行一层封装。
不过，很多人在封装时，总是习惯性地把 el-table 官方推荐的 "插槽写法" 改成 "JSON 数组" 写法。
就像这样：
<template>
<my-el-table :columns="columns" :data="tableData">
</my-el-table>
</template>
<script setup>
const columns = [
{
prop: 'date',
label: 'Date',
width: '180'
},
{
prop: 'name',
label: 'Name'
}
]
// ...其他略
</script>
但经过我多年踩坑的惨痛经历，我必须要大声说出那句话：
快住手！有更好的封装技巧！
JSON 式封装哪些缺点？
缺点一：学习成本增高
以下两种场景，如果是你今天刚刚入职，你更愿意在业务代码里看到哪种组件呢？
我反正是更偏向于 1 和 4！
第 1 种意味着它有丰富的社区支持，有准确而清晰的文档和 demo 可以借鉴。
第 4 种意味着你依然可以靠官方文档横行，并且可以使用一些同事根据业务进行的"增强能力"。
那么 2 和 3 呢？
也许我的同事真的可以做出很好的封装，但如果你在小厂、在初创公司、甚至在外包公司，更大的可能是你的同事并不靠谱。
他的某些封装只是为了满足单一的业务场景, 但你为了了解他的功能，却不得不去面对全新的 api，甚至是通过看他的源码才能了解具体有什么 api 和能力。
在这种场景下，我选择面对熟悉的，官方的 api。
缺点二：自定义内容需要写 h 函数
不会真的有人喜欢在业务里写
h函数吧？
当简单的 JSON 配置无法满足产品经理那天马行空的想象力时，你可能需要对 el-table-column 里的内容进行更多的自定义。
此时，也许你就会怀念"插槽式"的便捷了。
假设你的产品经理要求你写一个 带色彩的状态列 。
以上两种写法你会选择哪种呢？
而且，当业务变得更加复杂的时候，h 函数写法的可读性是指数式下跌的，你怕不怕？
当然，用JSX写法来简化
h函数写法是个不错的思路。
JSON 式封装有哪些优点？
优点一：能简化写法？（并不）
有人说：“ JSON 式封装，能够简化代码写法。”
听到这样的话，我的内心其实是充满困惑的：它究竟能简化什么？
看出来了吗？
这种常见的所谓 封装，只不过是做了做简单形式化的转换：你并没有少写哪怕一个属性，只不过把它们从这里挪到了那里。
甚至于极端场景，你还需要多写代码：
// 从：
<el-table-column show-overflow-tooltip />
// 变成：
{
'show-overflow-tooltip': true
}
优点二：只有 JSON 化才能实现动态列？（并不）
我在《我对 Element 的 Table 做了封装》 里讨论时， JackLiR8 同学提出了一个疑问：
简化一下就是：
怎样封装才能在保持插槽写法的情况下，实现
动态列呢 ？
其实这个问题并不难，前提是需要你理解 vNode 是什么以及怎么操作它们。
我做了一个简单的例子，核心代码如下：
// vue3 函数式组件写法
const FunctionalTable = (props, context) => {
// 获得插槽里的 vNodes
const vNodes = context.slots.default()
// 过滤 vNodes
const filteredVNodes = props.visibleKeys == null ? vNodes : vNodes.filter(node => props.visibleKeys.includes(node?.props?.prop))
// 把属性透传给el-table
return <el-table {...context.attrs}>
{ filteredVNodes }
</el-table>
}
// vue3 函数式组件定义 props
FunctionalTable.props = {
visibleKeys: {
type: Array,
default: () => null
}
}
这就能实现 动态列 了？
是的。
下面正是使用时的代码：
<template>
<el-button @click="onClick">给我变！</el-button>
<FunctionalTable :data="tableData" :visibleKeys="visibleKeys">
<el-table-column prop="date" label="Date" width="180" />
<el-table-column prop="name" label="Name" />
<el-table-column prop="address" label="Address" />
</FunctionalTable>
</template>
<script setup>
// 其他略
const visibleKeys = ref(['date', 'name'])
const onClick = () => {
visibleKeys.value = ['date', 'name', 'address']
}
// 其他略
// ...
效果如下：
毫无疑问，当遇到复杂场景，以及列里需要渲染各种奇形怪状的东西如 tag、popover 或者你需要进行更加复杂的定义的时候，插槽写法是更为优秀的。
这是上述demo的源代码 => github源码
优点三：JSON 配置能存数据库？（我劝你慎重）
"如果我把列的
JSON配置存到数据库里，那我就不用写代码了！"
好家伙，我直呼好家伙！
除非你已经封装了非常成熟的可视化配置方案，否则！ 当业务上需要新增一列时，不还是你写？服务端和运维可不会帮你写代码。
只不过你存储代码的地点，从
git变成了数据库。
碰上懒一点的服务端，你还需要安装数据库链接软件，增加一项写 sql update 语句的活儿。
更让人感到害怕的是，你丢失了对代码版本跟踪的能力。
"为啥生产库/测试库/开发库存的数据不一样，到底应该用谁，我也不知道这字段是哪个版本、因为什么被谁合入的呀...."
那一刻，你可能会无比怀念 git commit-msg 那。
我期望的封装是什么样的？
如果你想设计一款基于"element UI"或"element Plus"，能解决一些迫在眉睫的问题，能优化一些写法，能规范一些格式，能让团队小伙伴们乐于使用到组件库。
我想，你可能得充分考虑以下内容：
- 它的API是否简单易学（甚至大部分就和
element一模一样 ）？ - 它是否确确实实简化了业务上的写法？
比如把表格和分页器合并，比如提供请求方法作为prop等都是能极大降低业务复杂性的封装。 - 它是否扩展性强，易维护？
api设计是否和项目保持风格上的一致？
在同一个项目里，render/jsx/template混用很可能会让一些新人感到吃力。 - 它是否是增强和渐进的？
我可不希望当我试图使用elementUI某个特性时，我猛然发现我同事封装的组件居然不支持！
免喷声明
以上所有配图和文本都是我的个人观点。
如果你认为它们是错的，那它们就是错的吧。
关于我反对把 Element 表格列 JSON化 最初的初心，我确实厌倦了在不同团队不同公司总是要一遍又一遍去看前同事们蹩脚的封装，去理解他们做了哪些东西，拼写有没有改编，有没有丢失特性，去再学习一遍完全没有学习价值的API。
希望大家写代码时，都能获得良好的体验。
封装组件时，都能封装出"能用"，"好用"， "大家愿意用"的组件！
原文：https://juejin.cn/post/7043578962026430471
