2018-07-24
JiangRen Mr
One of the keys to writing a successful web application is being able to make dozens of AJAX calls per page.
This is a typical asynchronous programming challenge, and how you choose to deal with asynchronous calls will, in large part, make or break your app, and by extension potentially your entire startup.
Synchronizing asynchronous tasks in JavaScript was a serious issue for a very long time.
The first and the most straightforward solution came in the form of nested functions as callbacks. This solution led to something called callback hell, and too many applications still feel the burn of it.
Then, we got Promises. This pattern made the code a lot easier to read, but it was a far cry from the Don’t Repeat Yourself (DRY) principle. There were still too many cases where you had to repeat the same pieces of code to properly manage the application’s flow. The latest addition, in the form of async/await statements, finally made asynchronous code in JavaScript as easy to read and write as any other piece of code.
Let’s take a look at the examples of each of these solutions and reflect on the evolution of asynchronous programming in JavaScript.
To do this, we will examine a simple task that performs the following steps:
The ancient solution to synchronize these calls was via nested callbacks. This was a decent approach for simple asynchronous JavaScript tasks, but wouldn’t scale because of an issue called callback hell.
The code for the three simple tasks would look something like this:
const verifyUser = function(username, password, callback){
dataBase.verifyUser(username, password, (error, userInfo) => {
if (error) {
callback(error)
}else{
dataBase.getRoles(username, (error, roles) => {
if (error){
callback(error)
}else {
dataBase.logAccess(username, (error) => {
if (error){
callback(error);
}else{
callback(null, userInfo, roles);
}
})
}
})
}
})
};
Each function gets an argument which is another function that is called with a parameter that is the response of the previous action.
Too many people will experience brain freeze just by reading the sentence above. Having an application with hundreds of similar code blocks will cause even more trouble to the person maintaining the code, even if they wrote it themselves.
This example gets even more complicated once you realize that a database.getRoles
is another function that has nested callbacks.
const getRoles = function (username, callback){
database.connect((connection) => {
connection.query('get roles sql', (result) => {
callback(null, result);
})
});
};
In addition to having code that is difficult to maintain, the DRY principle has absolutely no value in this case. Error handling, for example, is repeated in each function and the main callback is called from each nested function.
More complex asynchronous JavaScript operations, such as looping through asynchronous calls, is an even bigger challenge. In fact, there is no trivial way of doing this with callbacks. This is why JavaScript Promise libraries like Bluebird and Q got so much traction. They provide a way to perform common operations on asynchronous requests that the language itself doesn’t already provide.
That’s where native JavaScript Promises come in.
Promises were the next logical step in escaping callback hell. This method did not remove the use of callbacks, but it made the chaining of functions straightforward and simplified the code, making it much easier to read.
With Promises in place, the code in our asynchronous JavaScript example would look something like this:
const verifyUser = function(username, password) {
database.verifyUser(username, password)
.then(userInfo => dataBase.getRoles(userInfo))
.then(rolesInfo => dataBase.logAccess(rolesInfo))
.then(finalResult => {
//do whatever the 'callback' would do
})
.catch((err) => {
//do whatever the error handler needs
});
};
To achieve this kind of simplicity, all of the functions used in the example would have to be Promisified. Let’s take a look at how the getRoles
method would be updated to return a Promise
:
const getRoles = function (username){
return new Promise((resolve, reject) => {
database.connect((connection) => {
connection.query('get roles sql', (result) => {
resolve(result);
})
});
});
};
We have modified the method to return a Promise
, with two callbacks, and the Promise
itself performs actions from the method. Now, resolve
and reject
callbacks will be mapped to Promise.then
and Promise.catch
methods respectively.
You may notice that the getRoles
method is still internally prone to the pyramid of doom phenomenon. This is due to the way database methods are created as they do not return Promise
. If our database access methods also returned Promise
the getRoles
method would look like the following:
const getRoles = new function (userInfo) {
return new Promise((resolve, reject) => {
database.connect()
.then((connection) => connection.query('get roles sql'))
.then((result) => resolve(result))
.catch(reject)
});
};
JavaScript is asynchronous by default. This might be reason why it took so long to get synchronous-looking code that runs properly in JavaScript. But, better late than never! The pyramid of doom was significantly mitigated with the introduction of Promises. However, we still had to rely on callbacks that are passed on to .then
and .catch
methods of a Promise
.
Promises paved the way to one of the coolest improvements in JavaScript. ECMAScript 2017 brought in syntactic sugar on top of Promises in JavaScript in the form of async
and await
statements.
They allow us to write Promise
-based code as if it were synchronous, but without blocking the main thread, as this code sample demostrates:
const verifyUser = async function(username, password){
try {
const userInfo = await dataBase.verifyUser(username, password);
const rolesInfo = await dataBase.getRoles(userInfo);
const logStatus = await dataBase.logAccess(userInfo);
return userInfo;
}catch (e){
//handle errors as needed
}
};
Awaiting Promise
to resolve is allowed only within async
functions which means that verifyUser
had to be defined using async function
.
However, once this small change is made you can await
any Promise
without additional changes in other methods.
Async functions are the next logical step in the evolution of asynchronous programming in JavaScript. They will make your code much cleaner and easier to maintain. Declaring a function as async
will ensure that it always returns a Promise
so you don’t have to worry about that anymore.
Why should you start using the JavaScript async
function today?
try
/catch
just like in any other synchronous code..then
block will not move to the next .then
because it only steps through synchronous code. But, you can step through await
calls as if they were synchronous calls.
IT Support 训练营01期
2025/11/10 06:13 (Sydney)
CCNA考证班01期
2025/09/06 08:37 (Sydney)
商业数据分析实战班第17期
2025/03/15 06:13 (Sydney)
地址
Level 10b, 144 Edward Street, Brisbane CBD(Headquarter)Level 2, 171 La Trobe St, Melbourne VIC 3000四川省成都市武侯区桂溪街道天府大道中段500号D5东方希望天祥广场B座45A13号Business Hub, 155 Waymouth St, Adelaide SA 5000Disclaimer
JR Academy acknowledges Traditional Owners of Country throughout Australia and recognises the continuing connection to lands, waters and communities. We pay our respect to Aboriginal and Torres Strait Islander cultures; and to Elders past and present. Aboriginal and Torres Strait Islander peoples should be aware that this website may contain images or names of people who have since passed away.
匠人学院网站上的所有内容,包括课程材料、徽标和匠人学院网站上提供的信息,均受澳大利亚政府知识产权法的保护。严禁未经授权使用、销售、分发、复制或修改。违规行为可能会导致法律诉讼。通过访问我们的网站,您同意尊重我们的知识产权。 JR Academy Pty Ltd 保留所有权利,包括专利、商标和版权。任何侵权行为都将受到法律追究。查看用户协议
© 2017-2024 JR Academy Pty Ltd. All rights reserved.
ABN 26621887572