前言
前端开发工程师，通常会作为开发阶段直接与客户需求进行深入对接的开发人员之一，我们所完成的一切都是为了给用户更好的体验。
而优化用户体验，常常我们会使用各种代码、产物的优化手段，比如：
- 代码混淆（去除文件可读性，替换长命名等，减少文件大小）
- gzip 压缩
- splitChunk 分包
- 异步加载
- 首页服务端渲染（SSR）
- 图片等资源压缩
- 第三方依赖 CDNs
- 资源缓存
当然上面这部分基本上都是用来处理最终的 js、css 等资源文件的操作，在我们编写代码时，一样也需要注意提高代码质量和性能。
另外，也是本文主要讲的一点：优化用户在操作上的体验。 这一节从 表格操作 来简单说明一下笔者的观点。
1. 背景
目前笔者所在的小组主要做后台系统和大屏可视化的相关开发。在开发阶段，我们的数据请求都是通过 axios.post 传递查询参数与分页参数来获取对应的表格/列表数据。该类型接口都统一接收分页参数 pageSize 和 pageNo 两个字段，分别表示单页数据条数和当前页；返回值都包含 data, msg, success, code 四个字段，其中 data 包含了 total 数据总条数与 list 当前页数据。
此时有两种情况会置空表格：
- 请求直接发送失败，或者服务端相应失败（http status code：40x、50x）
- 请求正确相应，但是查询失败（success 为 false）
另外还有一个优化需求：
当最后一页只有一条数据时，删除该数据应该将当前页 pageNo 向前翻页（只有一页时不变）
2. 处理方案
2.1 空表格处理
为了解决第一个问题，并且减少重复代码量，在 分页参数命名一致时，封装了一个 getEmptyTable 的方法。
/** * 重置一个空表格 * @param tableCallback 处理表格为空 * @param page 分页数据的引用地址 * @param { string | Error } msg 错误信息 * @return { number } total 返回数据总数，总是返回 0 */ export const getEmptyTable = (tableCallback, page, msg) => { tableCallback && tableCallback(); page && page.pageNo && (page.pageNo = 1); msg && Message.error(typeof msg === "string" ? msg : msg.toString()); return 0; // 作为 total 的返回 };
这里对这个函数进行一点解释：
- 为什么用回调函数而不是直接处理
this.xxx = []或者接收该数组作为参数？
这里一是为了减少之前的代码改动，因为每个人的命名习惯不一样，所以 table/list 对应绑定的数据命名也不一样；二是如果直接传递 this.xxx 作为参数指定表格，则内部重新赋值时只会改变函数内部变量的地址，不会影响原始数据（具体可以搜索函数的引用类型参数处理）
- msg 为什么有一个 字符串判断？
这也是为了减少使用时的重复操作。在请求发送异常时，可以直接传递 catch 的 error 错误对象
- return 0 的原因？
与第一点类似，也是因为不同开发者之间命名的问题；直接返回 0 可以直接在外面赋值给对应的 total 字段
大致使用场景如下：
<template> <div class="common-page"> <hwiot-table :data="tableData" size="small" border style="width: 100%"> </hwiot-table> <el-pagination background :current-page="page.pageNo" :page-size.sync="page.pageSize" :total="totalNum" :page-sizes="[10, 20, 50, 100]" layout="->, total, prev, pager, next, sizes, jumper" @current-change="currentChange" @size-change="currentChange(1)" /> </div> </template> <script> export default { name: "EquipLogService", data() { return { loading: false, searchForm: {}, page: { pageSize: 10, pageNo: 1 }, totalNum: 0, tableData: [] }; }, methods: { async getDeviceLogs() { try { this.loading = true; const { data, code, msg } = await this.$axios.post("/log/device/list", { ...this.searchForm, ...this.page }); if (code === 0) { this.tableData = data.list || []; this.totalNum = data.total; } else { this.totalNum = getEmptyTable(() => (this.tableData = []), this.page, msg); } } catch (e) { this.totalNum = getEmptyTable(() => (this.tableData = []), this.page, e); } finally { this.loading = false; } } } }; </script>
2.2 单页数据删除
上面说到了删除单页的最后一条数据时，应该将当前页向前分页。因为目前我们没有批量删除（虽然没有这个功能感觉很蠢），所以我们只是在删除时判断了当前表格数据的长度，为 1 时会在请求成功后将页数减少 1。
async getDevices(pageNo) { try { this.loading = true; const { data, success, msg } = await this.$axios.post("/device/list", { ...this.searchForm, pageNo: pageNo || this.page.pageNo, pageSize: this.page.pageSize }); if (success) { this.tableData = data.list || []; this.totalNum = data.total; } else { this.totalNum = getEmptyTable(() => (this.tableData = []), this.page, msg); } } catch (e) { this.totalNum = getEmptyTable(() => (this.tableData = []), this.page, e); } finally { this.loading = false; } } async deleteDevice(row) { try { const confirm = await this.$confirm(`是否确定删除该数据？`, "提示", { confirmButtonText: "确定", cancelButtonText: "取消", type: "warning" }); if (!confirm) return; const toLastPage = this.tableData.length === 1; const { success, msg } = await this.$axios.get("/device/delete", { params: { id: row.id } }); if (success) { this.$message.success(msg); this.getDevices(toLastPage ? this.page.pageNo - 1 : undefined); } else { this.$message.error(msg); } } catch (e) { console.error(e); } }
当然，如果是批量删除，其实也可以参照这个思路，在选中的删除数据长度等于当前页数据长度时，操作成功向前翻页即可。
这里在处理 get 数据获取请求时，也对 pageNo 进行了处理，避免为 0 或者 其他否定值，则还是使用当前页数设置。
当然，也可以直接将 table、operation、pagination 几个部分封装为一个组件，在内部进行统一处理。不过这种方式组件代码量太大，可以留给大家考虑一下😝
3. 最后
在细节操作上进行更好的处理和优化，当然也可以带来更好的用户体验，而作为提供给用户最直观感受的前端工程师，在优化用户体验的道路上从未停息。
类似上面介绍的两种处理方式，还有查询、搜索等表单 enter 提交，Message 类型提示信息合并，页面过渡动画，键盘快捷键操作、布局适配、按钮图标与文字间距等。
个人认为，处理好细节问题，也是我们通往更高层级的方式之一
