vue-element-admin中table分頁改成前臺處理

vue-element-admin中table分頁原理：根據currentPage與pageSize去後臺精準查詢，返回匹配的結果，而後前臺currentPage與pageSize變化時，再去後臺獲取相應的結果值。這樣的優勢：前臺存儲的資源少，壓力小。缺點：後端不斷接收請求的次數多。

我優化了一下，不能說優化，改造了一下，增長了另外一種分頁機制，後臺所有獲取數據，前臺經過computed獲得table要展現的data。這種優勢：當currentPage與pageSize變化時，不會去後臺請求數據，前臺根據vue的特性，數據雙向綁定，computed中自動計算應該展現的data。

 

改造內容：

一、原mock.js中filter部分，即下面這句話去掉。

　　　//const pageList = mockList.filter((item, index) => index < limit * page && index >= limit * (page - 1))//這種只把請求頁返給前臺

二、前臺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))

　　}

三、前臺vue部分 table綁定改成 

     　　:data="currentPageList"

四、增長新的分頁模版paginationNoRequestBack'

     　　import Pagination from '@/components/paginationNoRequestBack'

　  　　paginationNoRequestBack這個模版與pagination大同小異，只是將裏面的this.$emit('pagination')去掉了。

五、前臺vue部分 模版pagination調用裏面去掉@pagination事件。

 

目前項目中就存在了兩種分頁請求方式，在之後的使用中根據各自的優缺點，選取最優的方式便可。

固然新加的這種方式也可稱做‘假分頁’。

 

真分頁 和  假分頁，真分頁是不會去取全部數據的，假分頁雖然也達到了分頁效果，數據量少還好說，在將來數據量大的時候，接口性能就下降了。因此仍是看具體的業務場景。

「真分頁」顯然是效率更高,面對龐大的數據量也可以從容自若,可是缺點即是每次都須要和後臺交互。「假分頁」不須要和後臺交互,可是一旦面對大數據量時,加載將十分緩慢,影響用戶的體驗。

所以我的認爲數據量不是很大時，能夠考慮使用假分頁，這種只與數據庫請求一次。

補充點分頁SQL原理，參考： http://www.javashuo.com/article/p-hctdlaub-db.html