如何解决错综复杂的表格数据(GridManager随笔)

在前后端分离的开发模式中,处理表格数据格式是一大挑战。本文通过实例介绍如何在遇到后端返回的复杂数据格式时,使用GridManager组件解决冗余嵌套和字段不匹配问题,并探讨前端传参时如何处理分页参数配置,确保与后端顺利对接。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

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

后端返回数据

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

{
    "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

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值