vue-element-admin中table分页改为前台处理

vue-element-admin中table分页原理：根据currentPage与pageSize去后台精准查询，返回匹配的结果，然后前台currentPage与pageSize变化时，再去后台获取相应的结果值。这样的优点：前台存储的资源少，压力小。缺点：后端不断接收请求的次数多。

我优化了一下，不能说优化，改造了一下，增加了另一种分页机制，后台全部获取数据，前台通过computed得到table要展示的data。这种优点：当currentPage与pageSize变化时，不会去后台请求数据，前台根据vue的特性，数据双向绑定，computed中自动计算应该展示的data。

 

改造内容：

1、原mock.js中filter部分，即下面这句话去掉。

　　　//const pageList = mockList.filter((item, index) => index < limit * page && index >= limit * (page - 1))//这种只把请求页返给前台

2、前台vue部分处理，computed增加currentPageList()，在这个方法中将1中的计算逻辑加入

　　currentPageList() {

    　　var limitC = this.listQuery.limit

    　　var pageC = this.listQuery.page

    　　console.log("computed currentPageList this.list", this.list);

    　　if (this.list == null || this.list == undefined) {

    　　console.log("enter computed currentPageList()，但是还没有数据created（），等待。。。");

    　　return null;

　　　}

　　return this.list.filter((item, index) => index < limitC * pageC && index >= limitC * (pageC - 1))

　　}

3、前台vue部分 table绑定改为 

     　　:data="currentPageList"

4、增加新的分页模版paginationNoRequestBack'

     　　import Pagination from '@/components/paginationNoRequestBack'

　  　　paginationNoRequestBack这个模版与pagination大同小异，只是将里面的this.$emit('pagination')去掉了。

5、前台vue部分 模版pagination调用里面去掉@pagination事件。

 

目前项目中就存在了两种分页请求方式，在以后的使用中根据各自的优缺点，选取最优的方式即可。

当然新加的这种方式也可称作‘假分页’。

 

真分页 和  假分页，真分页是不会去取所有数据的，假分页虽然也达到了分页效果，数据量少还好说，在未来数据量大的时候，接口性能就降低了。所以还是看具体的业务场景。

“真分页”显然是效率更高,面对庞大的数据量也能够从容自若,但是缺点便是每次都需要和后台交互。“假分页”不需要和后台交互,但是一旦面对大数据量时,加载将十分缓慢,影响用户的体验。

因此个人认为数据量不是很大时，可以考虑使用假分页，这种只与数据库请求一次。

补充点分页SQL原理，参考：https://www.cnblogs.com/sunliyuan/p/5804355.html