摘要:异步时序问题吾辈的博客原文场景死后我们必升天堂,因为活时我们已在地狱。关键点异步操作得到结果的时间顺序是不确定的如果触发事件的频率较高异步操作的时间过长出现这种问题怎么解决既然关键点由两个要素组成,那么,只要破坏了任意一个即可。
JavaScript 异步时序问题
吾辈的博客原文:https://blog.rxliuli.com/p/de...场景
死后我们必升天堂,因为活时我们已在地狱。
不知你是否遇到过,向后台发送了多次异步请求,结果最后显示的数据却并不正确 -- 是旧的数据。
具体情况:
用户触发事件,发送了第 1 次请求
用户触发事件,发送了第 2 次请求
第 2 次请求成功,更新页面上的数据
第 1 次请求成功,更新页面上的数据
嗯?是不是感觉到异常了?这便是多次异步请求时会遇到的异步回调顺序与调用顺序不同的问题。
思考为什么会出现这种问题?
出现这种问题怎么解决?
为什么会出现这种问题?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. 后面异步操作得到结果后等待前面的异步操作返回结果
/** * 将一个异步函数包装为具有时序的异步函数 * 注: 该函数会按照调用顺序依次返回结果,后面的调用的结果需要等待前面的,所以如果不关心过时的结果,请使用 {@link switchMap} 函数 * @param fn 一个普通的异步函数 * @returns 包装后的函数 */ function mergeMap(fn) { // 当前执行的异步操作 id let id = 0 // 所执行的异步操作 id 列表 const ids = new Set() return new Proxy(fn, { async apply(_, _this, args) { const prom = Reflect.apply(_, _this, args) const temp = id ids.add(temp) id++ await wait(() => !ids.has(temp - 1)) ids.delete(temp) return await prom }, }) }
测试一下
;(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. 后面异步操作得到结果后放弃前面的异步操作返回结果
/** * 将一个异步函数包装为具有时序的异步函数 * 注: 该函数会丢弃过期的异步操作结果,这样的话性能会稍稍提高(主要是响应比较快的结果会立刻生效而不必等待前面的响应结果) * @param fn 一个普通的异步函数 * @returns 包装后的函数 */ function switchMap(fn) { // 当前执行的异步操作 id let id = 0 // 最后一次异步操作的 id,小于这个的操作结果会被丢弃 let last = 0 // 缓存最后一次异步操作的结果 let cache return new Proxy(fn, { async apply(_, _this, args) { const temp = id id++ const res = await Reflect.apply(_, _this, args) if (temp < last) { return cache } cache = res last = temp return res }, }) }
测试一下
;(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. 依次处理每一个异步操作,等待上一个异步操作完成之后再执行下一个
/** * 将一个异步函数包装为具有时序的异步函数 * 注: 该函数会按照调用顺序依次返回结果,后面的执行的调用(不是调用结果)需要等待前面的,此函数适用于异步函数的内里执行也必须保证顺序时使用,否则请使用 {@link mergeMap} 函数 * 注: 该函数其实相当于调用 {@code asyncLimiting(fn, {limit: 1})} 函数 * 例如即时保存文档到服务器,当然要等待上一次的请求结束才能请求下一次,不然数据库保存的数据就存在谬误了 * @param fn 一个普通的异步函数 * @returns 包装后的函数 */ function concatMap(fn) { // 当前执行的异步操作 id let id = 0 // 所执行的异步操作 id 列表 const ids = new Set() return new Proxy(fn, { async apply(_, _this, args) { const temp = id ids.add(temp) id++ await wait(() => !ids.has(temp - 1)) const prom = Reflect.apply(_, _this, args) ids.delete(temp) return await prom }, }) }
测试一下
;(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) })()小结
虽然三个函数看似效果都差不多,但还是有所不同的。
是否允许异步操作并发?否: concatMap, 是: 到下一步
是否需要处理旧的的结果?否: switchMap, 是: mergeMap
降低触发频率并限制异步超时时间思考一下第二种解决方式,本质上其实是 限流 + 自动超时,首先实现这两个函数。
限流: 限制函数调用的频率,如果调用的频率过快则不会真正执行调用而是返回旧值
自动超时: 如果到了超时时间,即便函数还未得到结果,也会自动超时并抛出错误
下面来分别实现它们
限流实现具体实现思路可见: 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 () => { let last = 0 let sum = 0 // 模拟一个异步请求,接受参数并返回它,然后等待指定的时间 async function get(ms) { await wait(ms) return ms } const time = 100 const fn = asyncTimeout(time, throttle(time, get)) await Promise.all([ fn(30).then(res => { console.log(res, last, sum) last = res sum += res }), fn(20).then(res => { console.log(res, last, sum) last = res sum += res }), fn(10).then(res => { console.log(res, last, sum) last = res sum += res }), ]) // last 结果为 10,和 switchMap 的不同点在于会保留最小间隔期间的第一次,而抛弃掉后面的异步结果,和 switchMap 正好相反! console.log(last) // 实际上确实执行了 3 次,结果也确实为第一次次调用参数的 3 倍 console.log(sum) })()
起初吾辈因为好奇实现了这种方式,但原以为会和 concatMap 类似的函数却变成了现在这样 -- 更像倒置的 switchMap 了。不过由此看来这种方式的可行性并不大,毕竟,没人需要旧的数据。
总结其实第一种实现方式属于 rxjs 早就已经走过的道路,目前被 Angular 大量采用(类比于 React 中的 Redux)。但 rxjs 实在太强大也太复杂了,对于吾辈而言,仅仅需要一只香蕉,而不需要拿着香蕉的大猩猩,以及其所处的整个森林(此处原本是被人吐槽面向对象编程的隐含环境,这里吾辈稍微藉此吐槽一下动不动就上库的开发者)。
可以看到吾辈在这里大量使用了 Proxy,那么,原因是什么呢?这个疑问就留到下次再说吧!
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/104673.html
摘要:模块化是随着前端技术的发展,前端代码爆炸式增长后,工程化所采取的必然措施。目前模块化的思想分为和。特别指出,事件不等同于异步,回调也不等同于异步。将会讨论安全的类型检测惰性载入函数冻结对象定时器等话题。 Vue.js 前后端同构方案之准备篇——代码优化 目前 Vue.js 的火爆不亚于当初的 React,本人对写代码有洁癖,代码也是艺术。此篇是准备篇,工欲善其事,必先利其器。我们先在代...
摘要:好吧,本文的主题可能还深入剖析的深复制前端掘金一年前我曾写过一篇中的一种深复制实现,当时写这篇文章的时候还比较稚嫩,有很多地方没有考虑仔细。 翻译 | 深入理解 CSS 时序函数 - 前端 - 掘金作者:Nicolas(沪江前端开发工程师) 本文原创,转载请注明作者及出处。 各位,赶紧绑住自己并紧紧抓牢了,因为当你掌握了特别有趣但又复杂的CSS时序函数之后,你将会真正体验到竖起头发般的...
摘要:回调函数不是由该函数的实现方直接调用,而是在特定的事件或条件发生时由另外的一方调用的,用于对该事件或条件进行响应。若是使用回调函数进行处理,代码就可以继续进行其他任务,而无需空等。参考理解回调函数理解与使用中的回调函数这篇相当不错回调函数 为什么写回调函数 对于javascript中回调函数 一直处于理解,但是应用不好的阶段,总是在别人家的代码中看到很巧妙的回调,那时候会有wow c...
摘要:函数会在之后的某个时刻触发事件定时器。事件循环中的这样一次遍历被称为一个。执行完毕并出栈。当定时器过期,宿主环境会把回调函数添加至事件循环队列中,然后,在未来的某个取出并执行该事件。 原文请查阅这里,略有改动。 本系列持续更新中,Github 地址请查阅这里。 这是 JavaScript 工作原理的第四章。 现在,我们将会通过回顾单线程环境下编程的弊端及如何克服这些困难以创建令人惊叹...
阅读 2378·2021-11-24 10:31
阅读 3429·2021-11-23 09:51
阅读 2240·2021-11-15 18:11
阅读 2389·2021-09-02 15:15
阅读 2453·2019-08-29 17:02
阅读 2288·2019-08-29 15:04
阅读 832·2019-08-29 12:27
阅读 2856·2019-08-28 18:15