ElementUi tab effect in the el-table

The reality of the scene very often experience excessive form el-table data for a better user experience, so we need to use the paging, paging can generally depends on the amount of data size can be divided into front-end and back-end control control.

Look at the effect (has to do desensitization treatment)

A distal el-table tab renderings

Examples ElementUi official put here to illustrate changes

<template>
    <el-table
        :data="tableData.slice((currentPage-1)*pagesize,currentPage*pagesize)"
        :stripe="stripe"
        :current-page.sync="currentPage"
        style="width: 100%">
        <el-table-column
            prop="date"
            label="日期"
            width="180">
         </el-table-column>
         <el-table-column
            prop="name"
            label="姓名"
            width="180">
         </el-table-column>
         <el-table-column
            prop="address"
            label="地址">
         </el-table-column>
    </el-table>
    <div class="pagination">
        <el-pagination
            @size-change="handleSizeChange"
            @current-change="handleCurrentChange"
            :page-sizes="[10, 15, 20]"
            :page-size="pagesize"
            layout="total, sizes, prev, pager, next, jumper"
            :total="total">
    </el-pagination>
</template> 

<script>
export default {
    data(){
        return{
            stripe: to true , // whether zebra table
            tableData: [],
            currentPage:1,
            pagesize:10,
            total:0,
        }
    },
    methods:{
        handleSizeChange(val) {
            this.pagesize=val;
        },
        handleCurrentChange(val) {
            this.currentPage = val;
        },
    }
}
<script>

The core is paging tableData.slice ((currentPage-1) * pagesize, currentPage * pagesize) that a code using a data slice method divides tableData sources, but in fact all the requested data, shown in Figure 2 and then realize the front page display fake.

 

 FIG 2 tableData actual requests all the data, the data of 13

Another idea is paged to the background value passed as a parameter currentPage and pagesize, telling the background, we need to [(currentPage-1) * pagesize, currentPage * pagesize] data this interval, so back to back.

Both methods have advantages and disadvantages, if the front end of the former paging control method, because essentially requested that all of the data , if the data is very large, involving hundreds, thousands or even tens of thousands of data, table of the first page loading time will be very slow, because it's data back to take over the user experience is very bad, memory space is also very friendly. Data clearly shows only dozens, but for this purpose have saved tens of thousands of pieces of data, like sql statement select * from and select [required fields] from the same apparent efficiency of the latter would be better. But it is also good, if the benefit is the case in a small amount of data, the first page of the table load speed of the user can accept, after the user clicks a button to switch page or jump directly to a page which does not need to initiate a request to display the data, very fast.

While the latter case the back-end control of pagination, every time you switch pages had initiated the request, after all, can not have both fish and bear's paw, we can only make adjustments according to the actual situation and user requirements.