Promise is the solution to asynchronous task synchronization? This article introduces Promise through the following aspects:
- What problem did Promise come along to solve
- Internal processing of a task within a Promise
- The standard specification for Promises
- Use the Promise method
- The Promise executes the order in the eventLoop
- The source address
Promise knowledge is divided into five chapters. In this chapter, we discuss: what problems do Promise appear to solve?
I. What problem does Promise appear to solve
- Fix the callback hell problem
- Solving trust Issues
- Ability to resolve catch errors
- After multiple tasks are called back, multiple tasks are executed in sequence, consuming too much performance
Fix the callback hell problem
First, we need to understand what a callback function is: a callback function refers to a function that is called back by the caller. The most common scenario in which “callback” is used in JS is of course asynchronous programming. “Callback hell” nesting means asynchronous nesting for example
setTimeout(() = >{
doSomething();
setTimeout(){
doSomething();
setTimeout(){
doSomething();
setTimeout(){
doSomething();
},1000};
},1000};
},1000}; .1000);
Copy the code
The layers of nesting, callbacks and callbacks make it hard to read, and promises are basically a list of the results of each execution, so the developer doesn’t have to remember the original execution order. At the same time, this “callback hell” creates another problem: trust.
Solving trust Issues
In terms of asynchronous requests, GitHub and its own XHR wrappers, such as Ajax, are callbacks from third-party libraries really reliable? Is the success or failure callback guaranteed to be called only once? If it doesn’t, it creates a lot of problems, like
- Callback too early (usually asynchronously called synchronously)
- Callback too late or no callback
- Too many callbacks
- , etc.
The root of its problem is inversion of control, in which control is given to a third party who decides when and how the callback is invoked. These errors are rare, but we still have to deal with them. This is where the solution becomes more important. Instead of canceling the inversion of control, the Promise reverses the control that was flipped out, which is to say, reversing the inversion of control. Promise has these characteristics: 1. Only one resolution can be made, and the resolution value can only be one, and cannot be changed after the resolution. 2. Any callback in then is called only once. So the Promise feature guarantees that promises can solve the trust problem.
Ability to resolve catch errors
The ability to catch an error that I understand here is not a callback with an error, but a non-promise invocation of an error callback. Promise will put all the statements that cause JS parsing to fail and raise an error exception into its own error callback, which will be passed as a parameter. For example:
p.then(res= > {
console.log('This is a callback to resovle. Then method', res);
console.log(undefinedData) // Undefined variable
})
.catch(reason= > {
console.log('This is a callback to reject. Catch method', reason);
})
Copy the code
In the. Then callback we execute an undefined value, and the JS interpreter should not find the value and raise Uncaught ReferenceError: UndefinedData is not defined, but in. Then it does not cause the program to fail to parse properly. Instead, it passes down to the. Catch method and passes an error message to the Reason argument. This behavior is the same function as a try/catch for synchronous tasks.