Scene
After death we will ascend to heaven, for we are already in hell when we live.
I don’t know if you have encountered it. I sent multiple asynchronous requests to the background, but the data displayed in the end is not correct - it is old data.
Specific situation:
- The user triggered an event and sent the first request
- The user triggered an event and sent the second request
- The second request is successful, update the data on the page
- The first request was successful, update the data on the page
Um? Did you feel an abnormality? This is the problem that the order of asynchronous callbacks and call orders encountered when multiple asynchronous requests are encountered.
think
- Why does this problem occur?
- How to solve this problem?
Why does this problem occur?
JavaScript is asynchronous everywhere, but it is not so easy to control. The user interacts with the UI, triggers the event and its corresponding processing functions. The function performs asynchronous operations (network request). The time (order) of the results obtained by the asynchronous operations is uncertain, so the time to respond to the UI is uncertain. If the frequency of the triggering event is high/the time for asynchronous operations is too long, the previous asynchronous operation results will overwrite the subsequent asynchronous operation results.
Key points
- The time (order) of the result obtained by asynchronous operations is uncertain
- If the frequency of the trigger event is high / the time for asynchronous operation is too long
How to solve this problem?
Since the key point is composed of two elements, just destroy any one.
- Manually control the order of asynchronous return results
- Reduce the trigger frequency and limit the asynchronous timeout
Manually control the order of the results returned
There are three different ideas according to the processing of asynchronous operation results.
- After the result is obtained, the result of the subsequent asynchronous operation is waiting for the previous asynchronous operation to return the result.
- After the result is obtained by the subsequent asynchronous operation, the previous asynchronous operation is given up and the result is returned.
- Process each asynchronous operation in turn, wait for the previous asynchronous operation to complete before executing the next one
Here we first introduce a common wait function
/**
* Wait for the specified time/wait for the specified expression to be true
* If no waiting conditions are specified, execute immediately
* Note: This implementation will have problems with macro tasks and micro tasks in nodejs 10. Remember that async-await is essentially the syntax sugar of Promise, but it is actually not a real synchronous function! ! ! Even in a browser, don't rely on this feature.
* @param param Waiting time/waiting condition
* @returns Promise object
*/
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. After the result is obtained, the result is waited for the previous asynchronous operation to return the result.
- Claim a unique id for each asynchronous call
- Use list to record all asynchronous ids
- After the asynchronous operation is actually called, add a unique id
- Determine whether the previous asynchronous operation is being executed is completed
- If the previous asynchronous operation is not completed, otherwise skip it
- Remove the current id from the list
- Finally wait for the asynchronous operation and return the result
/**
* Wrapping an asynchronous function as an asynchronous function with timing
* Note: This function will return the results in order according to the order of calls. The results of the subsequent calls need to wait for the previous one, so if you do not care about outdated results, please use the {@link switchMap} function
* @param fn A normal asynchronous function
* @returns wrapper function
*/
function mergeMap(fn) {
// The asynchronous operation currently performed id let id = 0
// List of asynchronous operations performed const ids = new Set()
return new Proxy(fn, {
async apply(_, _this, args) {
const prom = (_, _this, args)
const temp = id
(temp)
id++
await wait(() => !(temp - 1))
(temp)
return await prom
},
})
}
Test it
;(async () => {
// Simulate an asynchronous request, accept the parameter and return it, and then wait for the specified time async function get(ms) {
await wait(ms)
return ms
}
const fn = mergeMap(get)
let last = 0
let sum = 0
await ([
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)
// In fact, it was executed 3 times, and the result was indeed the sum of the 3 calls parameters (sum)
})()
2. After the result is obtained by the subsequent asynchronous operation, the previous asynchronous operation will be given up and returned.
- Claim a unique id for each asynchronous call
- Record the latest id of the asynchronous operation result
- Record the latest results of asynchronous operations
- Execute and wait for the return result
- Determine whether there are any calls that have already occurred after this asynchronous call
If so, return the result of the subsequent asynchronous call
Otherwise, the local asynchronous call id and its result will be the most [last]
Return the result of this asynchronous call
/**
* Wrapping an asynchronous function as an asynchronous function with timing
* Note: This function will discard expired asynchronous operation results, which will improve slightly (mainly because the faster response results will take effect immediately without waiting for the previous response results)
* @param fn A normal asynchronous function
* @returns wrapper function
*/
function switchMap(fn) {
// The asynchronous operation currently performed id let id = 0
// The id of the last asynchronous operation, the result of the operation smaller than this will be discarded let last = 0
// Cache the results of the last asynchronous operation let cache
return new Proxy(fn, {
async apply(_, _this, args) {
const temp = id
id++
const res = await (_, _this, args)
if (temp < last) {
return cache
}
cache = res
last = temp
return res
},
})
}
Test it
;(async () => {
// Simulate an asynchronous request, accept the parameter and return it, and then wait for the specified time async function get(ms) {
await wait(ms)
return ms
}
const fn = switchMap(get)
let last = 0
let sum = 0
await ([
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)
// In fact, it was executed 3 times, but the result is not the sum of the 3 calls parameters, because the results of the first two times were discarded, and actually returned the result of the last send request (sum)
})()
3. Process each asynchronous operation in turn, wait for the previous asynchronous operation to complete before executing the next one.
- Claim a unique id for each asynchronous call
- Use list to record all asynchronous ids
- Add a unique id to the list
- Determine whether the previous asynchronous operation is being executed is completed
- If the previous asynchronous operation is not completed, otherwise skip it
- Really call asynchronous operations
- Remove the current id from the list
- Finally wait for the asynchronous operation and return the result
/**
* Wrapping an asynchronous function as an asynchronous function with timing
* Note: This function will return the results in order according to the order of calls. The subsequent execution calls (not the result of the call) need to wait for the previous one. This function is suitable for the internal execution of asynchronous functions and must be used in order. Otherwise, please use the {@link mergeMap} function.
* Note: This function is actually equivalent to calling the {@code asyncLimiting(fn, {limit: 1})} function
* For example, save the document to the server immediately, of course, you have to wait for the last request to end before requesting the next time, otherwise there will be a fallacy in the data saved in the database.
* @param fn A normal asynchronous function
* @returns wrapper function
*/
function concatMap(fn) {
// The asynchronous operation currently performed id let id = 0
// List of asynchronous operations performed const ids = new Set()
return new Proxy(fn, {
async apply(_, _this, args) {
const temp = id
(temp)
id++
await wait(() => !(temp - 1))
const prom = (_, _this, args)
(temp)
return await prom
},
})
}
Test it
;(async () => {
// Simulate an asynchronous request, accept the parameter and return it, and then wait for the specified time async function get(ms) {
await wait(ms)
return ms
}
const fn = concatMap(get)
let last = 0
let sum = 0
await ([
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)
// In fact, it was executed 3 times, but the result is not the sum of the 3 calls parameters, because the results of the first two times were discarded, and actually returned the result of the last send request (sum)
})()
summary
Although the three functions seem to have similar effects, they are still different.
- Is asynchronous operations allowed to be concurrent? No: concatMap, Yes: to the next step
- Do you need to deal with old results? No: switchMap, Yes: mergeMap
Reduce the trigger frequency and limit the asynchronous timeout
Think about the second solution, which is essentially current limit + automatic timeout, first implement these two functions.
- Current limit: Limits the frequency of function calls. If the frequency of the call is too fast, the call will not be executed but will return the old value.
- Automatic timeout: If the timeout time is reached, even if the function has not yet obtained the result, it will automatically time out and an error will be thrown.
Implement them separately below
Current limit implementation
The specific implementation ideas can be seen:JavaScript anti-shake and throttling
/**
* Function throttling
* Throttle: Make a function not executed too frequently, and reduce calls that are executed too quickly, which is called throttle.
* Similar to the above but different from the above function debounce, after the wrapping function, the minimum interval time will be executed after the last operation has passed, otherwise the operation will be ignored.
* The obvious difference from the above function debounces when continuous operations are performed at the minimum interval time instead of just performing the last operation
* Note: This function will be executed for the first time. There is no need to worry about not getting the cache value for the first time. The subsequent consecutive calls will get the cache value for the last time.
* Note: High-order functions that return function results need to be implemented using {@link Proxy} to avoid information loss on the original function prototype chain
*
* @param {Number} delay Minimum interval time in ms
* @param {Function} action What really needs to be performed
* @return {Function} A function with throttling function after wrapping. This function is asynchronous and has no much correlation with whether the function {@link action} needs to be wrapped is asynchronous or not
*/
const throttle = (delay, action) => {
let last = 0
let result
return new Proxy(action, {
apply(target, thisArg, args) {
return new Promise(resolve => {
const curr = ()
if (curr - last > delay) {
result = (target, thisArg, args)
last = curr
resolve(result)
return
}
resolve(result)
})
},
})
}
Automatic timeout
Note: The asyncTimeout function is actually just to avoid a situation where the asynchronous request time exceeds the minimum interval time of the throttling function, resulting in the order of return of the result.
/**
* Add automatic timeout function to asynchronous functions
* @param timeout timeout
* @param action asynchronous function
* @returns Async function wrapped
*/
function asyncTimeout(timeout, action) {
return new Proxy(action, {
apply(_, _this, args) {
return ([
(_, _this, args),
wait(timeout).then(),
])
},
})
}
Use in combination
Test it
;(async () => {
// Simulate an asynchronous request, accept the parameter and return it, and then wait for the specified time 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 ([
fn(30).then(res => {
last = res
sum += res
}),
fn(20).then(res => {
last = res
sum += res
}),
fn(10).then(res => {
last = res
sum += res
}),
])
// The last result is 10. The difference between switchMap is that it retains the first time during the minimum interval, and abandons the subsequent asynchronous result, which is exactly the opposite of switchMap! (last)
// In fact, it was executed 3 times, and the result was 3 times the first call parameter (sum)
})()
At first we realized this because of curiosity, but we thought we would be able to do it.concatMapSimilar functions have become what they are now - more like invertedswitchMapNow. However, from this point of view, this method is not very feasible, after all, no one needs old data.
Summarize
In fact, the first implementation method belongs to the path that rxjs has long taken, and is currently widely adopted by Angular (compared to Redux in React). But rxjs is too powerful and too complicated. For us, we only need a banana, not a gorilla holding the banana, and the entire forest where we live (this place was originally a hidden environment for object-oriented programming, so we use this to complain about the developers who always use the library).
You can see that we use it here in large quantitiesProxy, So, what is the reason? Let’s leave this question until next time!
The above is the detailed content of JavaScript asynchronous timing issues. For more information about JavaScript asynchronous timing, please pay attention to my other related articles!