【工作实践篇】等待轮询结果后再发请求

为啥会有这篇 ？

• 一些同学说 想看 工作中常用的一些操作分享， 它来了

在一些场景下我们需要去重复请求接口 数据

经典场景

1. 多人点单 选择商品后需要 重复拉取 order 接口 获取最新订单信息
2. 审批状态比如多个人都在审批一个单 当一个人审批了 更改了审批状态 需要通知其他人 
...... 

实现

• 其实 实现轮询 非常 简单* 先给一个 最简单轮询版本```
  this.timer = setInterval(async () => {await this.getList()
  },2000)

// 然后在适当时机清楚（比如 离开页面）
clearInterval(this.timer)

* 看起来 非常 简单 问题是 setInterval 并不会自我清除

`更优雅的方式`
--------

* 这样的好处是 setTimeout 会在每次结束 清除自己 且在 恰当时机 执行 time = 0 , 此处需要了解一下 宏认为/微任务* 但 无法解决 等待轮询结果后再发请求```
this.timer = setInterval(() => {
setTimeout(()=> {
...
},0)
},2000)

// 然后在适当时机清楚（比如 离开页面）
clearInterval(this.timer) 

• （条件 网络 low 3G模拟接口慢的情况 轮询1s 测试快速发请求情况）

这样实现后 大概是 这样

• 我们可以 很明确的发现 前一条 没有请求结束 后一条请求 又跟上了* 会出现这样的情况

• 出现多个地方 接口 报错 ！ 非常 不 nice

再优雅一波

const STATUS_INTERVAL = 2 * 1000const queryOrderStatus = () => {this.timer = setTimeout(async () => {await xxxxxqueryOrderStatus();}, STATUS_INTERVAL);};queryOrderStatus();// 然后在适当时机清楚（比如 离开页面）
clearInterval(this.timer) 

• 实现效果

• 有没有想过为啥 ？ 递归 和 await 功效 good* 如果多个 请求 可叠加 / Promise.all(…)* 更多 技术实践 正在袭来 …

最后

整理了一套《前端大厂面试宝典》，包含了HTML、CSS、JavaScript、HTTP、TCP协议、浏览器、VUE、React、数据结构和算法，一共201道面试题，并对每个问题作出了回答和解析。

有需要的小伙伴，可以点击文末卡片领取这份文档，无偿分享

部分文档展示：

文章篇幅有限，后面的内容就不一一展示了

有需要的小伙伴，可以点下方卡片免费领取