提交按钮没防抖，差点影响了项目验收

前言

一个运行了多年的ToB的项目，由于数据量越来越大，业务越来越复杂，也一直在迭代，今年的阶段性交付那几天，公司 最大的客户 现场那边人员提出，某某某单据页面速度太慢了，点击会出现没反应的情况，然后就多点了几次，结果后面发现有的数据重复提交了，由于数据错误个别单据流程给弄不正常了，一些报表的数据统计也不对了，客户相关人员很不满意，马上该交付了，出这问题可还了得，项目款不按时给了，这责任谁都担不起🤣

领导紧急组织相关技术人员开会分析原因

初步分析原因

发生这个情况前端选手应该会很清楚这是怎么回事，明显是项目里的按钮没加防抖导致的，按钮点击触发接口，接口响应慢，用户多点了几次，可能查询接口还没什么问题，如果业务复杂的地方，部分按钮的操作涉及到一些数据计算和后端多次交互更新数据的情况，就会出现错误。

看下项目情况

用到的框架和技术

项目使用 angular8 ts devextreme 组合。对！这就是之前文章提到的那个屎山项目（试用期改祖传屎山是一种怎么样的体验）

项目规模

业务单据页面大约几百个，项目里面的按钮几千个，项目里面的按钮由于场景复杂，分别用了如下几种写法：

• dx-button
• div
• dx-icon
• input type=button
• svg

由于面临交付，领导希望越快越好，最好一两天之内解决问题

还好我们领导没有说这问题当天就要解决 😁

解决方案

1. 添加防抖函数

按钮点击添加防抖函数，设置合理的时间

function debounce(func, wait) {
  let timeout;
  return function () {
    if(timeout) clearTimeout(timeout);
    timeout = setTimeout(func, wait)
  }
}

优点

封装一个公共函数，往每个按钮的点击事件里加就行了

缺点

这种情况有个问题就是在业务复杂的场景下，时间设置会比较棘手，如果时间设置短了，接口请求慢，用户多次点击还会出现问题，如果时间设置长了，体验变差了

2. 设置按钮禁用

设置按钮的 disabled 相关属性，按钮点击后设置禁用效果，业务代码执行结束后取消禁用

this.disabled = true
this.disabled = false

优点

原生按钮和使用的UI库的按钮设置简单

缺点

div, icon, svg 这种自定义的按钮的需要单独处理效果，比较麻烦

3. 请求拦截器中添加loading

在请求拦截器中根据请求类型显示 loading，请求结束后隐藏

优点

直接在一个地方设置就行了，不用去业务代码里一个个加

缺点

由于我们的技术栈使用的 angular8 内置的请求，无法实现类似 axios 拦截器那种效果，还有就是项目中的接口涉及多个部门的接口，不同部门的规范命名不一样，没有统一的标准，在实际的业务场景中，一个按钮的行为可能触发了多个请求，因此这个方案不适合当前的项目

4. 添加 loading 组件（项目中使用此方案）

新增一个 loading 组件，绑定到全局变量中，按钮点击触发显示 loading，业务执行结束后隐藏。

loading 组件核心代码

import { Injectable } from '@angular/core';
import { BehaviorSubject } from 'rxjs';
@Injectable({
  providedIn: 'root'
})
export class LoadingService {
  private isLoading$ = new BehaviorSubject<boolean>(false);
  private message$ = new BehaviorSubject<string>('正在加载中...');
  constructor() {}
  show(): void {
    this.isLoading$.next(true);
  }
  hide(): void {
    this.isLoading$.next(false);
  }
}

主要是 show() 和 hide() 函数，将 loading 组件绑定到 app.components.ts 中，绑定组件到window 对象上，

window['loading'] = this.loadingService

在按钮点击时触发 show() 函数，业务代码执行结束后触发 hide() 函数

window['loading'].show();
window['loading'].hide();

优点

这种方式很好的解决了问题，由于 loading 有遮罩层还避免了用户点击某提交按钮后，接口响应慢，这时候去点击了别的操作按钮的情况。

缺点

需要在业务单据的按钮提交的地方一个个加

问题来了，一两天解决所有问题了吗？

这么大的项目一两天不管哪种方案，把所有按钮都处理好是不现实的，经过分析讨论，最终选择了折中处理，先把客户提出来的几个业务单据页面，以及相关的业务单据页面添加上提交 loading 处理，然后再一边改 bug 一边完善剩余的地方，优先保证客户正常使用

还有更好的解决思路吗？欢迎评论区讨论交流