时间:2021-05-26
场景
死后我们必升天堂,因为活时我们已在地狱。
不知你是否遇到过,向后台发送了多次异步请求,结果最后显示的数据却并不正确 – 是旧的数据。
具体情况:
嗯?是不是感觉到异常了?这便是多次异步请求时会遇到的异步回调顺序与调用顺序不同的问题。
思考
为什么会出现这种问题?
JavaScript 随处可见异步,但实际上并不是那么好控制。用户与 UI 交互,触发事件及其对应的处理函数,函数执行异步操作(网络请求),异步操作得到结果的时间(顺序)是不确定的,所以响应到 UI 上的时间就不确定,如果触发事件的频率较高/异步操作的时间过长,就会造成前面的异步操作结果覆盖后面的异步操作结果。
关键点
出现这种问题怎么解决?
既然关键点由两个要素组成,那么,只要破坏了任意一个即可。
手动控制返回结果的顺序
根据对异步操作结果处理情况的不同也有三种不同的思路
这里先引入一个公共的 wait 函数
/** * 等待指定的时间/等待指定表达式成立 * 如果未指定等待条件则立刻执行 * 注: 此实现在 nodejs 10- 会存在宏任务与微任务的问题,切记 async-await 本质上还是 Promise 的语法糖,实际上并非真正的同步函数!!!即便在浏览器,也不要依赖于这种特性。 * @param param 等待时间/等待条件 * @returns Promise 对象 */function wait(param) { return new Promise(resolve => { if (typeof param === 'number') { setTimeout(resolve, param) } else if (typeof param === 'function') { const timer = setInterval(() => { if (param()) { clearInterval(timer) resolve() } }, 100) } else { resolve() } })}1. 后面异步操作得到结果后等待前面的异步操作返回结果
测试一下
;(async () => { // 模拟一个异步请求,接受参数并返回它,然后等待指定的时间 async function get(ms) { await wait(ms) return ms } const fn = mergeMap(get) let last = 0 let sum = 0 await Promise.all([ fn(30).then(res => { last = res sum += res }), fn(20).then(res => { last = res sum += res }), fn(10).then(res => { last = res sum += res }), ]) console.log(last) // 实际上确实执行了 3 次,结果也确实为 3 次调用参数之和 console.log(sum)})()2. 后面异步操作得到结果后放弃前面的异步操作返回结果
是的话就直接返回后面的异步调用结果
否则将本地异步调用 id 及其结果最为[最后的]
返回这次的异步调用结果
测试一下
;(async () => { // 模拟一个异步请求,接受参数并返回它,然后等待指定的时间 async function get(ms) { await wait(ms) return ms } const fn = switchMap(get) let last = 0 let sum = 0 await Promise.all([ fn(30).then(res => { last = res sum += res }), fn(20).then(res => { last = res sum += res }), fn(10).then(res => { last = res sum += res }), ]) console.log(last) // 实际上确实执行了 3 次,然而结果并不是 3 次调用参数之和,因为前两次的结果均被抛弃,实际上返回了最后一次发送请求的结果 console.log(sum)})()3. 依次处理每一个异步操作,等待上一个异步操作完成之后再执行下一个
测试一下
;(async () => { // 模拟一个异步请求,接受参数并返回它,然后等待指定的时间 async function get(ms) { await wait(ms) return ms } const fn = concatMap(get) let last = 0 let sum = 0 await Promise.all([ fn(30).then(res => { last = res sum += res }), fn(20).then(res => { last = res sum += res }), fn(10).then(res => { last = res sum += res }), ]) console.log(last) // 实际上确实执行了 3 次,然而结果并不是 3 次调用参数之和,因为前两次的结果均被抛弃,实际上返回了最后一次发送请求的结果 console.log(sum)})()小结
虽然三个函数看似效果都差不多,但还是有所不同的。
降低触发频率并限制异步超时时间
思考一下第二种解决方式,本质上其实是 限流 + 自动超时,首先实现这两个函数。
下面来分别实现它们
限流实现
具体实现思路可见: JavaScript 防抖和节流
/** * 函数节流 * 节流 (throttle) 让一个函数不要执行的太频繁,减少执行过快的调用,叫节流 * 类似于上面而又不同于上面的函数去抖, 包装后函数在上一次操作执行过去了最小间隔时间后会直接执行, 否则会忽略该次操作 * 与上面函数去抖的明显区别在连续操作时会按照最小间隔时间循环执行操作, 而非仅执行最后一次操作 * 注: 该函数第一次调用一定会执行,不需要担心第一次拿不到缓存值,后面的连续调用都会拿到上一次的缓存值 * 注: 返回函数结果的高阶函数需要使用 {@link Proxy} 实现,以避免原函数原型链上的信息丢失 * * @param {Number} delay 最小间隔时间,单位为 ms * @param {Function} action 真正需要执行的操作 * @return {Function} 包装后有节流功能的函数。该函数是异步的,与需要包装的函数 {@link action} 是否异步没有太大关联 */const throttle = (delay, action) => { let last = 0 let result return new Proxy(action, { apply(target, thisArg, args) { return new Promise(resolve => { const curr = Date.now() if (curr - last > delay) { result = Reflect.apply(target, thisArg, args) last = curr resolve(result) return } resolve(result) }) }, })}自动超时
注: asyncTimeout 函数实际上只是为了避免一种情况,异步请求时间超过节流函数最小间隔时间导致结果返回顺序错乱。
/** * 为异步函数添加自动超时功能 * @param timeout 超时时间 * @param action 异步函数 * @returns 包装后的异步函数 */function asyncTimeout(timeout, action) { return new Proxy(action, { apply(_, _this, args) { return Promise.race([ Reflect.apply(_, _this, args), wait(timeout).then(Promise.reject), ]) }, })}结合使用
测试一下
;(async () => { // 模拟一个异步请求,接受参数并返回它,然后等待指定的时间 async function get(ms) { await wait(ms) return ms } const time = 100 const fn = asyncTimeout(time, throttle(time, get)) let last = 0 let sum = 0 await Promise.all([ fn(30).then(res => { last = res sum += res }), fn(20).then(res => { last = res sum += res }), fn(10).then(res => { last = res sum += res }), ]) // last 结果为 10,和 switchMap 的不同点在于会保留最小间隔期间的第一次,而抛弃掉后面的异步结果,和 switchMap 正好相反! console.log(last) // 实际上确实执行了 3 次,结果也确实为第一次次调用参数的 3 倍 console.log(sum)})()起初吾辈因为好奇实现了这种方式,但原以为会和 concatMap 类似的函数却变成了现在这样 – 更像倒置的 switchMap 了。不过由此看来这种方式的可行性并不大,毕竟,没人需要旧的数据。
总结
其实第一种实现方式属于 rxjs 早就已经走过的道路,目前被 Angular 大量采用(类比于 React 中的 Redux)。但 rxjs 实在太强大也太复杂了,对于吾辈而言,仅仅需要一只香蕉,而不需要拿着香蕉的大猩猩,以及其所处的整个森林(此处原本是被人吐槽面向对象编程的隐含环境,这里吾辈稍微藉此吐槽一下动不动就上库的开发者)。
可以看到吾辈在这里大量使用了 Proxy,那么,原因是什么呢?这个疑问就留到下次再说吧!
以上就是JavaScript 异步时序问题的详细内容,更多关于JavaScript 异步时序的资料请关注其它相关文章!
声明:本页内容来源网络,仅供用户参考;我单位不保证亦不表示资料全面及准确无误,也不保证亦不表示这些资料为最新信息,如因任何原因,本网内容或者用户因倚赖本网内容造成任何损失或损害,我单位将不会负任何法律责任。如涉及版权问题,请提交至online#300.cn邮箱联系删除。
同步时序逻辑电路与异步时序逻辑电路的区别如下: 1、核心逻辑不同 异步电路电路的核心逻辑是组合电路,比如异步的FIFO/RAM读写信号、地址译码信号等电路。
异步编程带来的问题在客户端Javascript中并不明显,但随着服务器端Javascript越来越广的被使用,大量的异步IO操作使得该问题变得明显。许多不同的方
浅析javascript异步执行函数导致的变量变化问题解决思路for(vari=0;i
javascript中事件冒泡和事件捕获机制的详解二者作用:描述事件触发时序问题事件捕获:从document到触发事件的那个节点,即自上而下的去触发事件---由
JavaScript是单线程运行,异步操作特别重要。只要用到引擎之外的功能,就需要跟外部交互,从而形成异步操作。由于异步操作实在太多,JavaScript不得不