elementUI table树形懒加载,如何实现数据更新
最近在实现需求的时候遇到这种问题,觉得挺有意思的,过程也没有特别的煎熬,废话不多说,直接开始说。
问题抛出
在做后台项目的时候,经常会有这样的需求:
table的树形结构,而且由于数据量比较多的时候,更加需要做的就是懒加载。当然element非常贴心的提供了相关的方法:
只需要配置
row-key,lazy,以及load函数
在load函数的提供的resolve放进去数据,那么就可以实现子项数据的懒加载。
当然,这些都不会实现都不是本文的重点,这些都可以通过element的官方文档可以解决问题,今天的第一个重点是,下图所示:
当你的子项数据可以操作的时候,如图上的,取消发布功能,那么你就需要重新更新这条数据的状态,问题是,这个懒加载的数据,element并不会给你放回去
children
里面(看tree-props的配置)
,这就意味着这些数据都是另外渲染出来的,那么我要怎么样才能重新更新这些数据的状态呢?
懒加载数据的更新
其实很容易想到,既然elementUI提供了,更新数据的方法,我们只需要将这些东西存起来,到子项触发完状态的时候,再请求接口,将数据重新放到更新方法里,是不是就可以实现到,懒加载数据的更新呢?这里给出的例子都是伪代码,各位可以根据自己的需求实现
,我们先给出数据格式,如下:
const table = [
{
id: 1,
parent_id: 0,
name: '父级1',
children: [],
hasChildren: true,
},
{
id: 2,
parent_id: 0,
name: '父级2',
children: [],
hasChildren: true,
}
]
const lazyData = [
{
id: 11,
parent_id: 1,
name: '父级1-子级1',
},
{
id: 12,
parent_id: 1,
name: '父级1-子级2',
},
]
接下来开始第一步的操作,由于我们需要记录到element提交的方法,同时为了绑定方法的关系,这里我选择id作为绑定的点,这时候我们就可以使用Map数据结构来实现了:
//
data() {
return {
mapData: new Map(),
};
},
接着,我们需要在load函数里面保存我们需要的东西:
load(tree, treeNode, resolve) {
// 保存子项的方法
if (!this.mapData.has(tree.id)) {
this.mapData.set(tree.id, { tree, treeNode, resolve });
}
}
我们可以通过判断parent_id的值,来区分到底是子项触发的事件,还是父项触发的事件,伪代码如下:
if (data.parent_id === 0) {
// 更新父项请求方法
} else {
// 子项点击发布或者取消发布时,更新子项方法
const { tree, treeNode, resolve } = this.mapData.get(
data.parent_id,
);
this.load(tree, treeNode, resolve);
}
从而完成了子项数据的更新。
懒加载数据清空
除了上面的这种只是改变数据状态的操作,有时候我们也需要删除掉子项的需求,如下:
实际上,删除操作跟上面更新数据,基本上是一样的,就是对数据的更新,element给的方法,有个致命的缺点,那就是,如果你给的数据是空数组的话,那么子项数据就不会更新!!由于这个问题,我就不得不去查看elementUI的源码,有了下面的发现:点这里
从上图可以发现,实际上element源码是对这个
lazyTreeNodeMap
更新值,从而渲染子项的,那么我们就只可以在空数据的时候,用相同的方式去更新这个值,从而实现数据清空的实现。
从上图可以发现,实际上lazyTreeNodeMap的键实际上就是,一开始我们绑定的row-id,参考我们上面的数据结构的话,就可以得到下面的大致实现。
const lazyTreeNodeMap = {
11 : [],
12 : []
}
// 通过ref的方式获取到lazyTreeNodeMap
this.$refs.table.store.states.lazyTreeNodeMap
最后,我们只需要对接口返回的数据进行空判断,就可以执行下面的伪代码:
if (data.length === 0) {
this.$set(
this.$refs.table.store.states.lazyTreeNodeMap,
son.parent_id,
[],
);
}
总结
过程其实非常的煎熬,特别是在找源码的时候,结果是好的,而且也没因此的加班。时隔接近一年了,才写了这边找错 文章。
转载自:https://juejin.cn/post/7245201923505274940