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

简介: 项目提交按钮没防抖,差点影响了验收

前言

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

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

初步分析原因

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

看下项目情况

用到的框架和技术

项目使用 angular8tsdevextreme 组合。对!这就是之前文章提到的那个屎山项目(试用期改祖传屎山是一种怎么样的体验

项目规模

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

  • 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 一边完善剩余的地方,优先保证客户正常使用

还有更好的解决思路吗?欢迎JYM讨论交流

目录
相关文章
|
7月前
|
小程序
小程序一直未提审的原因及解决方案
小程序一直未提审的原因及解决方案
90 11
|
3月前
|
缓存 监控 前端开发
前端代码评审问题总结年度代码翻车现场 |
团队已持续进行了一年多的线下周代码评审,作为主要评审人,我认识到虽然初衷是提供代码改进建议,但实际上大部分问题集中在基础代码质量上,而非设计或业务逻辑。因此,团队需保持耐心,逐步解决基础问题。本文总结了一年来常见的代码评审问题,如魔法值、eslint禁用、幽灵依赖等,并提出具体改进建议。此外,还强调了良好的代码习惯、命名规范及异常处理的重要性。通过持续代码评审,希望团队能在卓越工程的道路上不断进步。以下是常见问题的具体分析: ### 二、翻车现场(CR中的常见问题) #### 2.1 代码规范类 ##### 2.1.1 使用魔法值 - **危害**:代码不易读、不复用、易出错 - **建
36 3
|
7月前
|
缓存 前端开发 JavaScript
年度代码翻车现场 |前端代码评审问题总结
代码评审于技术团队的工程师文化建设非常有意义,它是形成团队统一代码风格最有效的方式,作者把自己团队在一年的CR中常见的那些小问题做了一些梳理,希望能对大家起到一点小帮助。
219826 7
|
7月前
|
前端开发 BI
项目提交按钮没防抖,差点影响了验收
项目提交按钮没防抖,差点影响了验收
|
前端开发 Shell 程序员
🙊整活向:定期给老板推送同事的代码量
总有领导想把公司往倒闭里整。但是每天推送每个人的代码量倒是挺有趣的,git log本身就自带这个功能,不来看看吗?
175 0
🙊整活向:定期给老板推送同事的代码量
|
监控 安全 架构师
抱歉,你测试的项目上线之后bug太多了!
抱歉,你测试的项目上线之后bug太多了!
|
测试技术 Linux Windows
禅道项目管理软件 为提交Bug页面添加“优先级”字段
禅道项目管理软件 为提交Bug页面添加“优先级”字段
166 0
|
iOS开发
没有做ipad适配被驳回了咋办?
没有做ipad适配被驳回了咋办?适配器被拒有好的解决方法提供吗?
没有做ipad适配被驳回了咋办?
|
存储 Unix 程序员
被通知一个月后离职,我改了重要项目里的代码注释
假如你已经对某个开发人员下发解雇通知,你还会让他深度参与重要项目甚至把项目做完再走吗?放在今天,这个答案往往是显而易见的:不会。但如果是几十年前,那就未必了。
243 0
被通知一个月后离职,我改了重要项目里的代码注释