不知各位有没有遇到在需求为主，配置化为辅的今天，关联方的操作使的应该是正常的逻辑变的不可理喻。比如我这次遇到了大哥，我们是通过接口获取他们的数据，但是他们的数据参数起名随意（2022年了，我竟然看见返回参JSON某些属性名叫fct，sbt），不看需求（关于参数的时间他们不同意），告诉我们数据量大，但是不提供分页。
在经过一天的交涉下，我们后端竟然聊出了高血压，在领导的据理力争下，结果就是他们领导牛，按他们想发做。。。
问了一下数据量，也就一百条不到，想着后端好哥们经常分享下午茶，我就和他沟通，让他直接把数据全部给我，我来分页。
<template>
<el-table :data="tableData" style="width: 100%">
<el-table-column v-for="(item, index) in tableTemplate" :key="item + index" :prop="item.code" :label="item.label" min-width="160" />
</el-table>
<el-pagination
@size-change="handleSizeChange"
@current-change="handleCurrentChange"
:current-page.sync="page"
:page-sizes="[5, 10, 15]"
:page-size="pageSize"
layout="sizes, prev, pager, next"
:total="total" />
</template>
data() {
return {
total: null,
pageSize: 5,
page: 1,
loading: false,
tableData: [],
tableTemplate: [
{ label: '保单号', code: 'policyNum' },
{ label: '描述', code: 'description' },
{ label: '姓名', code: 'username' },
{ label: '手机号', code: 'mobile' },
{ label: '地址', code: 'address' },
]
}
},上面就是一个简单的结构，肯定不能给真实数据和请求，而且该功能是查询，有包括查询条件和效验就简单跳过，重点是看怎么假分页。
data () {
return {
tableList: [], // 展示的表格的数据
AllList: [] // 全部数据
}
}
methods: {
async getList () {
let _this = this
// ... 该处是一些非空校验和一些清空数据
_this.page = 1
const params = {...} // 基础请求参数
_this.loading = true
try {
const res = await getPolicyList(params)
if(res.status !== 'success') {
_this.$message.warning(res.message)
_this.loading = false
}
const { list, total } = res.data
_this.AllList = _this.cuttingArray(list)
_this.tableList = _this.AllList.find(item => item.page === _this.page).list
_this.loading = false
} catch (_) {
// ... 失败的操作
}
},
cuttingArray (arr) {
if(!arr) return []
let newArr = []
let num = 0
for (let i = 0; i < arr.length; i+=this.pageSize) {
if(i + this.pageSize <= arr.length) {
newArr.push({
page: num += 1,
list: arr.slice(i, i + this.pageSize)
})
} else {
newArr.push({
page: num += 1,
list: arr.slice(i, i + arr.length)
})
}
}
return newArr
}
}在data中添加tableList和AllList，记清楚他们一个是后端返回的你处理过的所有数据，另一个是你用来展示的table的数据。
getList中我省略了一些清除数据和效验的操作，但是记得，这个请求是每次点查询时触发的，使用必须将page赋值为1，清空tableList和AllList的原数据，记得是必须！还有既然已经获取全部数据，条数和页码是我们前端自己用的，不用给后端了。
在获取到全部数据后，将数据处理执行cuttingArray方法，他会使用for循环遍历，每次根据你的条数跳着遍历并切割数组。
假如获取到的总数据为16条，你的条数为一页10条，他第一次遍历时， i为0，判断 i 加上当前条数 （11）是否小于或等于传入的arr的length（16），发现小于时，num + 1， list 是 使用 arr的slice方法切割 i（0）- pageSize（10）条并返回给list，这就是分页的第一页。
因为 i 每次遍历都会加上当前条数，所以第2次时 i 为 11，再经过判断时，i 加 pageSize (21)已经超过arr的length（16），再切割时，会切割 i (11) - arr.length(16) 并返回给list，这正好是总数剩下的末页。
methods: {
handleCurrentChange (page) {
this.page = page || 1
this.tableList = this.AllList.find(item => item.page === this.page).list
},
handleSizeChange (size) {
this.pageSize = size || 10
this.getList()
}
}还有处理页码和翻页事件时注意，因为切割时我们往里面放了page ，所以和上面一样根据page查询list并赋给tableList即可，但是修改条数就必须要走请求了，但是我们cuttingArray方法是根据条数切割数组，并且发送请求前我们还会修改页码为第一页，所以完美实现假分页。
因为第一期的计划仅仅是展示表格，所以点操作修改状态有没有我不知道，但是如果要实现也非常简单，点击事件时拿到id，根据page修改AllList的状态再根据页码赋值给tableList，类似于下面，只要修改总数据，任他怎么点状态都没问题，当然要走请求改一下那条数据。
// ... 一些根据id修改状态的请求，就算假分页，改状态也要走请求，不然再获取一次总数组状态不就没了
_this.AllList = _this.AllList.map(item => {
if(item.page === _this.page) {
item.list = item.list.map(maSon => {
if(maSon.id === id) {
// ... 在这里修改状态
}
return maSon
})
}
return item
})
this.tableList = this.AllList.find(item => item.page === this.page).list和他们沟通了3天，我们的代码2个小时开发完成并联调测试完成，甚至没到吃饭的时就结束了，问一下关联方他们什么时候联调，他告诉我们7月中旬。。。
最后大家记住，这种假分页是实在没办法才采用的，数据一多，查询时的loading就要老半天，而且大家看见改状态多麻烦，有条件该怎么正常给后端 页码和条数 就怎么正常做，他返回什么你展示什么多舒服啊，不要一天天想秀什么操作，我敢肯定后端一定也有假分页，但是这次算我抢功能，所以问题也是我来担。
当然，基本上不会有问题，有只要找到方法也肯定能解决！
最后祝大家身体健康！
