自从前后端分离的模式推广以后,前后端的开发人员就开始了针对于数据格式的相爱相杀。

后端返回数据

对我们前端来言,后端小哥的一些神返回实在难以理解。
我们做个表格,所期望的后端返回数据格式是这样的:

{
    "list":[
        {
            "name": "baukh",
            "age": "28",
            "info": "野生前端程序"
        },
        {
            "name": "baukh",
            "age": "28",
            "info": "野生前端程序",
        }
    ],
    "totals": 2
}

但是后端小哥一顿操作猛如虎,返回以下格式:

{
    code: 200,
    msg: 'success',
    data: { // 期望返回的数据不包含这一层
        "data":[
            {
                "name": "baukh",
                "birthday": "1995-03-12", // 期望返回的是age,但是返回的是生日
                "info": "野生前端程序",
            },
            {
                "name": "baukh",
                "birthday": "1995-03-12",
                "info": "野生前端程序"
            }
        ],
        "sum": 2 // 期望返回的是totals,但是返回的是生日
    }
}

然后给你留下一句,框架如何如何、分页组件如何如何。。空留下目瞪狗呆的你。

但前端的表格组件也需要固定的格式,你心里想:"要不是看你长的五大三粗的,真想顶你个肺咧"。

但问题还是要解决的,接下来看下在GridManager组件中是如何解决这个问题的:

解决冗余嵌套问题

前端需要返回的对像中包含总条数与当前页的数据集合,但后端不仅字段不匹配而且还在此基础上又包了一层结构。

此时可通过执行请求后执行程序responseHandler对数据进行整理:

new GridManager(table, {
    responseHandler: function(response){
        const year = new Date().getFullYear();
        return {
             list: response.data.data.map(item => {
                 item.age = year - item.birthday.split('-')[0]; // 为每条数据增加age属性, 也可以在columnData.template中进行处理(下方有示例)。
                 return item;
             }),
             totals: response.data.sum
        };
    },
    // 其它配置项...
});

解决字段不匹配问题

刚改完,后端小哥说了:"我也觉着多的那层没什么用,我刚已经把那层移掉了"。于是打开network,发现数据格式已经变成了这个样子:

{
    "data":[
        {
            "name": "baukh",
            "birthday": "1995-03-12", // 期望返回的是age,但是返回的是生日
            "info": "野生前端程序",
        },
        {
            "name": "baukh",
            "birthday": "1995-03-12",
            "info": "野生前端程序"
        }
    ],
    "sum": 2 // 期望返回的是totals,但是返回的是生日    
}

强忍着即将爆发的的小宇宙,安慰着自已: 把responseHandler中的response.data.data改成response.data就好了。
但GridManager早就想到了这种情况,此时有更简单的方式:

new GridManager(table, {
    dataKey: 'list', // 指定数组 key 为 list
    totalsKey: 'sum', // 指定总数 key 为 sum
    // 其它配置项...
});

前端传参

改完后,来了波后端请求。一个醒目的500状态码映入眼前,你知道那response里指不定还有个空指针。

细细的一品,发现原来是后端小哥秀了一波英语四六级。

之前谈好的分页参数是这样的: cPage为当前页, pSize为每页显示条数。

后端小哥本着英语要写就要写全的缩指,给你整成了这个样式: currentPage为当前页, pageSize为每页显示条数。

。。。

分页参数key配置

问题还是要解决的,来看看在GridManager中怎么处理这种情况的:

new GridManager(table, {
    currentPageKey: 'currentPage', // 指定当前页 key 为 currentPage
    pageSizeKey: 'pageSize', // 指定每页显示条数 key 为 pageSize
    // 其它配置项...
});

页面开发完了,后端小哥也满意了。原本觉着可以泡杯coffee来犒劳下自已了,谁知产品绕到背后: "加个排序功能呗"。

拉着后端小哥的手,终于定好了万年不变的排序参数:

{
    px_birthday: 'down' // 你当然会吐槽,刚英语还过了四六级,这会拼音指序都用了。
}

有了一个确定的数据格式,一切就简单了。

new GridManager(table, {
    sortKey: 'px_', // ajax请求中排序字段所使用的前缀,默认为`sort_`
    sortDownText: 'down', // 指定降序所使用的字符串
    sortUpText: 'up', // 指定升序所使用的字符串
    columnData: [
        {
            key: 'name',
            text: '姓名'
        },
        {
            key: 'birthday',
            text: '生日',

            // 列的排序信息。字符串类型,非必设项
            // 1、'': 该列支持排序,但初始化时不指定排序类型
            // 2、'DESC': 该列支持排序,并指定为降序。可通过参数[sortDownText]来指定降序所使用的字符串
            // 3、'ASC': 该列支持排序,并指定为升序。可通过参数[sortUpText]来指定升序所使用的字符串
            sorting: '', 
            template: (birthday, row) => {
                return new Date().getFullYear() - birthday.split('-')[0]; // 可以实现与responseHandler中同样的效果
            }

        }
    ]
    // 其它配置项...
});

做完后,产品也满意思了。你心想,还好产品没再提个组合排序功能。

如果想了解组合排序,请查看GridManager API


写个程序换个饼
114 声望10 粉丝

静看人世风雨 、凝聚人生魅力。