问题

由于项目初期没有考虑到列表字段增多，导致进入页面之后等待请求时间过长（后端查询关联字段的表都有七八个，一个请求要到1～1.5s），用户体验非常不好。但是用户已经习惯在界面上看到这么多字段了，所以突然减少字段的显示会造成困扰。怎么样才能解决这样的问题呢？

选择方案

  • 向后端发送需要的字段，后端精准查询。

  • 分步请求。先请求主表的数据，关联表在主表数据完成之后再请求。

确定方案

第一种方案是最开始提出的方案，但是一看代码才发现想法虽然好，但是没办法实现，因为我们的表格有个表格视图的功能，它的主要功能是可以让用户自定义表格显示多少字段（其实选择较少的字段可以提高前端渲染的速度，但是后端查询速度是没办法提高的），这些字段是保存在后端的，所以第一次加载的时候并不知道有哪些字段显示，还要等表格视图的请求完才知道，这样就更慢了…

所以最终决定使用第二种方案。

验证方案

当时想到这个方案的时候是给否定的，因为在第一次加载之后去再去发送请求，然后再将数据组合显示，js代码的运行会阻塞页面的渲染，所以在实施之前，还得验证一下可行性。

方案没有确定之前，最后还是前端先验证一下，思来想去这种有关请求的验证该怎么做呢？

答案当然是…

抓包咯……

抓包对于解决有关请求的问题实在是太好用了，之前就用来重现过线上的BUG，目前windows平台上比较好用（对我而言）的是Fiddler，思路其实也很简单，修改请求返回的内容：

  1. 先将客户端获取的json数据保存起来processes_old.json。
  2. 然后从json文件中抽取部分字段出来processes_next.json.
  3. 再将剩下的字段保存起来processes.json。
  4. 打开Fiddler，找的AutoResponder，添加请求地址对应的返回数据。
  5. 再在代码中计算所用时间。
// 点击menu时,用全局变量记录下当前时间。
window.Timing = new Date().getTime();

// 在loading结束之后得到用时
console.log('loading end', new Date().getTime() - window.Timing);
  1. loading结束之后，页面已经显示完毕，再请求关联表的内容，然后将关联表的内容与之前的数据相结合。
// 假设两次请求的数据顺序是一样的
const success = data => {
    this.tableData = this.tableData.map((d, i) => Object.assign(d, data[i]))  
}

这样就能对比出请求耗时是否减少，第二次请求是否会影响用户交互了。

注：因为项目两个相邻菜单的请求类似（就几个参数的差别），所以非常适合用来对比速度，其中一个菜单采用processes_old.json的数据，另外一个采用processes.json和processes_next.json的数据。

验证结果

事实证明此方案是可行的，将Chrome devTools的Network中网络改成Fast 3G可以感受到明显的差别。

在第二次请求时也感受不到卡顿。

所以，结论是放心大胆的用吧！

方案实施

实施就交给后端吧…前端已经做好了😊。