The topic is a little big, for the friends who pay attention to the front end circle, this topic also falls into a bit of cliche, as sen aunt’s first article, also hope to write a little fresh feeling and small enlightenment. Auntie Sen promises to be absolutely original. As we all know, the JS world is single-threaded, meaning that only one task can be completed before another task can be performed. This is because JS runs in a host multi-scripting language, such as a browser or node, and the host process allocates only one JS engine thread to it. For a long operation, if you continue to wait, you may be hurt, the user experience will be compromised, and you won’t be able to do anything. So, we need some way to avoid waiting for an operation that takes a lot of time, which leads to asynchrony. Don’t worry, how does the engine know how long an operation will take when it hasn’t done it and when it will? The best way to really understand a mechanic is to try to design it ourselves. Now, stop and think for yourself, if we were developing a browser engine, what would we do? A lot of things, we write every day, every day in the browser engine running on hundreds of millions of machines, looks so natural, natural to we forget to think that behind the reason and logic, and think this is how it should be, we are enjoying a mellifluous predecessors to give everything, forget we first open the editor, on the first line of code when dreams. You may be angry and ask, if it were me, why not multithread js? Most languages are multithreaded, such as c++, such as Java, and you’ve probably been to the water cooler to wash your cups and heard that rd guy on the back end is always asking how to solve the problem of thread communication when interviewing candidates. However, while Java is designed for different manipulation tasks and data, we write HTML, CSS and JS that are essentially web oriented and, ultimately, operate on the DOM elements of the browser. And browser rendering DOM elements, the most afraid is redraw and reflux, and multi-threading dom manipulation, will inevitably lead to higher complexity, as well as a higher probability of redraw and reflux. The browser divides tasks into two types: synchronous tasks and asynchronous tasks. Single threading of JS means that only one JS task is running at the same time, other synchronous tasks are queued later, and asynchronous tasks are queued. The browser itself is not single-threaded; it has the EventLoop polling thread, the UI rendering thread, and the network request thread…… And so on. There are many other threads doing different tasks. The synchronous task is directly queued by the JS parsing thread, while the asynchronous task is suspended by the executing thread and enters the message queue. The main thread uses the callback function to tell the main thread that its task is finished and no longer needs to wait, so that the main thread will put the task in the queue waiting for execution. We will see in many articles the term ‘execution stack’, which Aunt Sen does not want to use, because we all know that stack is first in, last out, and this JS execution is first come, first served. The term ‘execution stack’ here does not refer to JS tasks, but rather to the amount of memory allocated for their execution. The benefit of the computer is sincere, everything is so orderly, not to the human, did not finish the execution, the first cry to the end of the execution, what queue-jumping ah plug ah, all do not exist, all the tasks are in accordance with the rules set up in order to run. Our CPU speed is far higher than the speed of network I/O transmission, in today’s data-driven and MVVM popularity, a large number of asynchronous operations are filled with our code, one after another callback, so that our code has no sense of design and difficult to reuse and maintenance. In ES6, Promise was finally introduced as a natively supported method in browsers, which we see as essentially syntactic sugar, and a lot of things in ES6 can be considered syntactic sugar. Without it, our lives could go on, and we could quickly write logic and code to meet our business needs and earn a paycheck. But, but life is short, only you sweet, only you sweet. What’s wrong with being sweet? What’s wrong with being sweet? We have to learn all kinds of new technology, read all kinds of articles, contact all kinds of new terms, a lot of front end old people suffer unbearably, a lot of front end novice novice car corners. First, the disadvantages of the callback function: 1) callback hell, cumbersome; 2) The code structure is chaotic, and the synchronous and asynchronous tasks are stacked and mixed; 3) Irrelevant to the sense of design, unable to use advanced design patterns; 4) All functions and logic are realized by callback, which is not convenient for reuse by other modules; 5) Repetition and redundancy. Promises can be written as asynchronous procedures in sequence, for example:
new Promise(testFunction).then(function (result) {
}).catch(function (reason) {
}).then(function (result) {
}).catch(function (reason) {
}).then(function (result) {
}).catch(function (reason) {
});
Copy the codeThen, even if we don’t write a return value, each promise step will have a default return value, called undefined. Promises are compliant with the A+ specification, and we can implement promises ourselves and test them using the A+ specification. Promise has three states: pending, resolved and Rejected. This promise can be translated into Chinese, because it will never change once it is reached or rejected. It is sincere and measured, it is not a person, it is just so simple.