Developing Async Sense

Developing Async Sense
Nemanja Stojanovic @nem035

Inspirations
Kyle Simpson (@getify) - YDKJS
Jake Archibald (@jaffathecake) - html5rocks, Google
Douglas Crockford - JavaScript The Good Parts

💡❓🤔 ��
Why did that not
work?
W
hy did that work?
I get it !!! 
Take that JavaScript

What is Async?
Sync is two things happening chronologically one after the other
Make 🍞
⏲ for it
Cut 🍅
Async is two things happening chronologically independent of one another
Make 🍞
Cut 🍅
⏲ for it

Treads
One piece of code -> Simultaneous code execution, sharing resources

Treads Sandwich
One piece of code -> Simultaneous code execution
if not 🍞, make 🍞
if not 🍅, cut 🍅
if not 🍞, make 🍞
if not 🍅, cut 🍅
🍞🍅
You Your Clone
Possible outcomes
🍞🍞🍅
🍞🍅🍅
🍞🍞🍅🍅

arr.length
arr.push('b');
arr.length
arr.push('a');
arr.lengtharr.length
arr.push('a');arr.push('a');
if (arr.length == 1) {
arr.push('b');
}
arr.push('b');
}
arr.push('a');
arr.push('b');
arr.length
arr.push('a');
Possibility 1 Possibility 2
[ ] [ ]'a''a', 'b', 'a', 'a'
arr.push('a');
arr.push('b');
}
arr.length
arr.push('b');
}
Possibility 3
[ ]'a','a', 'b'

Problems with Threads
- Data Corruption Risks
Shared Memory -> Races who gets to the shared data ﬁrst

Deadlocks -> Two (or more) threads waiting on each other
- System gets completely blocked

Confusing ﬂow control and timing issues
Difﬁcult to reason about

Tread-safe code
Mutual Exclusion (Mutex)
- Semaphores, monitors, synchronization
Mutex is a program object that prevents simultaneous
access to a shared resource.
- Each critical section is executed once per thread

Tread-safe Sandwich
One piece of code -> mutexed code execution
mutex if not 🍞, make 🍞
mutex if not 🍅, cut 🍅
mutex if not 🍞, make 🍞
mutex if not 🍅, cut 🍅
🍞🍅
You Your Clone
Possible outcomes

lock(); // lock execution to the current thread
arr.push('a');
arr.push('b');
}
unlock(); // free execution for the next thread
Only possible output: [ ]'a''a', 'b',
Tread-safe code

JavaScript
Everything runs and shares the same thread:
- JS Engine, DOM, CSS Engine …
Browser has multiple queues (Event, Render, Network…) 
and it might perform actions from any of the queues 
(depending on priority, efﬁciency…), but can only do one at a time
Single Threaded

JavaScript - Single Threaded
Only one thing can happen at a time (Single Call Stack)
Async code runs after the stack is empty
Async code doesn’t block the UI because its processed later

JS Engine
JS Code has the Run-to-Completion semantic
Function code is atomic (once a function starts it has to ﬁnish)
That’s why if the CSS Engine wants to repaint but JS is still
running we get jerkiness
Highest priority in the JS Thread

Run-to-Completion
Each Queued task (click event, render, ajax response) is processed
completely
- No other queue task can be processed until current one is ﬁnished
Important
If a message takes too long to complete, the web application is unable to
process user interactions (like click or scroll).
Each function runs in full
- No other function can run while another function is running

Why does this matter?
Analogy: 
Because being on hold sucks.
Imagine having the customer service call you when they’re available.
Much better, right?
Good UX === Non-Blocking
Who cares?

How do we not block then?
Callbacks

JS Code
var one = getOneSync();
getThreeAsync((three) => {
alert(three);
});
var two = getTwoSync();
getThreeAsync((three) => {
alert(three);
});
setTimeout((three) => {
alert(three);
});
NOW
LATER

Output?
console.log('A');
setTimeout(() => {
console.log('B');
}, 1000);
console.log('C');
Console: 
'A' 
'C' 
'B'

Output?
console.log('A');
setTimeout(() => {
console.log('B');
}, 0);
console.log('C');
Console: 
'A' 
'C' 
'B'

Event Loop
Inﬁnitely looping looking for new tasks to execute.
A single iteration is called a tick.
The code executed during a tick is called a task.
Cannot execute a task while either JS code or another task is running

function eventLoop() {
// perform loop ticks, "forever"
while (true) {
var nextTask = taskQueue[0];
nextTask();
}
}

Event Loop
Tasks are synchronous
Tasks may schedule other tasks in the loop.
Tasks may come from other sources such as user events,  
networking or DOM manipulation.

console.log('A');
setTimeout(function cb() {
console.log('B');
}, 1000);
console.log('C');
Console
Task Queueconsole.log('A');
'A'
console.log('C');
cb()
'C' 'B'
console.log('B');
}, 1000);
BrowserCall Stack
log('A')setTimeout()log('C')
Wait 1secconsole.log('B');
log('B')

console.log('A');
console.log('B');
}, 0);
console.log('C');
Console
Task Queueconsole.log('A');
'A'
console.log('C');
cb()
'C' 'B'
console.log('B');
}, 0);
BrowserCall Stack
log('A')setTimeout()log('C')
Wait .004secconsole.log('B');
log('B')
Wait until  
Stack is Empty

Why is setTimeout(cb, 0) useful?setTimeout(cb, 0)
Defer code execution until the Call Stack is empty
Add heavy-weight code to the end of the Event Loop
Allow browser to re-render and/or process events  
before executing our code

Example
function process(data) {
var chunk = data.slice(0, 10); // take first 10 items
//... do heavy-weight stuff with the chunk
// stick this function at the end of the event queue
setTimeout(() => {
// continue processing the data after Call Stack is clear
process(data.slice(10))
}, 0);
}

Callbacks
A callback function is a function which is:
- passed as an argument* to another function, and,
- is invoked after some kind of event.
*Because JS functions are ﬁrst-class functions

Callbacks
Building blocks of asynchronous JS.

Ok, callbacks are great. 
 
But… are there any problems with them?

Callback Hell
httpGet('/stories/' + storyId, function (story) {
httpGet(story.chapterUrls[0], function (chapter) {
httpGet(chapter.pageUrls[0], function (page) {
var chapterJSON = JSON.parse(chapter);
displayChapter(chapterJSON);
});
});
Most known callback issue - Pyramid of doom

Pyramid of Doom - Solved?
httpGet('/stories/' + storyId, processStory);
 
function processStory(story) {
httpGet(story.chapterUrls[0], processChapter);
}
function processChapter(chapter) {
httpGet(chapter.pageUrls[0], processPage);
}
function processPage(page) {
var chapterJSON = JSON.parse(chapter);
displayChapter(chapterJSON);
}

Turns out… there’s a lot more
Reaction order is difﬁcult to maintain
Error are hard to handle (ﬂow branches on errors)
- Require manual error handling (no try/catch)
Success/Error path logic has to be hardcoded
- Unmaintainable
Non-Sequential
Flow
}
- Require maintaining state in the global scope
Mixing input and output
- Tie up async operation with our reaction to it

And some more…
Being called too many times
Swallowing errors or exceptions
Unreliable Execution
}
No built-in protection against:
Being called too early

Non-Sequential Flow
Callbacks - Getting two values in parallel?
httpGet(url1, function(res) {
// here we have value 1
});
// here we have value 2
});
function processValues(value1, value2) {
// how do we know when we have both?
}

function(res) {
value1 = res;
if (typeof value2 !== 'undefined') {
processValues(value1, value2);
}
var value1, value2; var value1, value2;
value1 = res;
}
});
value2 = res;
}
});
function(res) {
value2 = res;
}
Maintain state externally
Repetition (not DRY)
Non-Sequential Flow

processValues(values.value1, values.value2);
var values = { value1: undefined, value2: undefined };
var hasValues = { value1: false, value2: false };
httpGet(url1, getRequestHandler('value1'));
httpGet(url2, getRequestHandler('value2'));
function getRequestHandler(valueNum) {
return function(res) {
hasValues[valueNum] = true;
values[valueNum] = res;

if (hasValues.value1 && hasValues.value2) {
}
}
}
function(res) {
hasValues[valueNum] = true;
values[valueNum] = res;

if (hasValues.value1 && hasValues.value2) {
}
}
getRequestHandler('value2')
getRequestHandler('value1')
var values = { value1: undefined, value2: undefined };
var hasValues = { value1: false, value2: false };
DRY
Non-Sequential Flow

What if we were getting more than 2
things in parallel?

What if we wanted to make parallel request but process
data as soon as it’s received and in some order?

Let’s say we want to request value1 and value2 at the
same time but process them in order (value1 then value2)

processValue(value2);
value2 = result;
value1 = result;
value1 received ﬁrst
1. receive value1
2. process value1
3. receive value2
4. process value2
var value1, value2;
value1 = result;
}
});
value2 = result;

}
});

var value1, value2;
value1 = result;
}
});
value2 = result;

}
});
value2 = result;
value1 = result;
value2 received ﬁrst
1. receive value2
2. receive value1
3. process value1
4. process value2

sendPurchaseOrder(books[0].url, function() {
});
getBooks(store.booksUrl, function(books) {

;
});
Unreliable
getStore(url, function (store) {

});
displaySuccessDialog();
Can we guarantee that getStore wont call its callback twice which
would call getBooks twice and then send two purchase orders?
How about if getBooks sometimes returns an invalid url array?

var hasExecuted = false;
processValue(res);
var hasExecuted = false;
if (!hasExecuted) {
hasExecuted = true;
processValue(res);
}
});
A callback that runs once
Non-Sequential Flow

Error Handling
Separate handlers for success and fail cases
$.ajax({
success: function() {
// ...
},
error: function() {
// ...
}
})

$.ajax({
},
error: function() {
 
}
})
- Reduces (somewhat) the issue of 
Non-Sequential Flow by splitting logic
// success path// ...
// ...// error path

$.ajax({

},
error: function() {

}
})
Doubles our need for protection 
against Unreliable Execution
because now we have two
callbacks to worry about instead of
one
I am unreliable
Me too!
// Not called on time?
// Not called at all? 
// Called to many times?
// Not called on time?
// Not called at all? 
// Called to many times?

What if res is an invalid JSON?
Bloat code with noise by
requiring error handling
logic in every callback
Error Handling
function getJSON(url, cb) {
httpGet(url, function(err, res) {
if (err) {
cb(err);
} else {
cb(null, JSON.parse(res))
}
});
}
Error-ﬁrst style callbacks

What if cb() throws an error?
function cb(err, json) {
throw Error('Error within cb()')
}
if (err) return cb(err);
try {
cb(null, JSON.parse(res));
} catch(err) {
cb(err);
}
});
}
Error Handling Error-ﬁrst style callbacks

try {
res = JSON.parse(res);
} catch(err) {
return cb(err);
}
cb(null, res);
});
}
Ok, we are handling errors
Error Handling Error-ﬁrst style callbacks
But… can we easily
reason about this code?

Non-Sequential Flow Unreliable Execution
Thunks ???
Solutions?

Thunks
Wrappers around callbacks
Eliminate time as a concern
Conceptual base for promises
Wrappers around future values

function(cb) {
if (typeof value === 'undefined') {
callback = cb;
} else {
cb(value);
}
}
function httpGetThunk(url) {
var value, callback;

if (typeof callback === 'undefined') {
value = res;
} else {
callback(res);
}
});
return function(cb) {
callback = cb;
} else {
cb(value);
}
}
}
value = res;
} else {
callback(res);
}
});
- Return a function that
accepts a callback which will
provide the value, sometime
in the future.
- Run the async function when
created
- Wrap around a callback and
a future value

var thunk = httpGetThunk(url);
thunk(function(result) {
// here we have the result
});
How do we use it?

One of:
1. Cache the callback
and call it with a value later
2. Cache the value and
pass it into a callback later

value = res;
} else {
callback(res);
}
});
callback = cb;
} else {
cb(value);
}
}
}
callback = cb;
callback(res);
cb(value);
value = res;


value = res;
} else {
callback(res);
}
});
callback = cb;
} else {
cb(value);
}
}
}
callback = cb;
callback(res);
We call the function
returned from the thunk
before the httpGet ﬁnishes
Option 1
1. Cache the callback
2. httpGet responds and
we call the cached callback


value = res;
} else {
callback(res);
}
});
callback = cb;
} else {
cb(value);
}
}
}
value = res;
cb(value);
We receive the value from
httpGet before the
callback is called
Option 2
1. Cache the value
2. Our returned function is
called and we call the callback

That means we can write async code and pretend
that we already have the value
Whenever the value arrives is irrelevant!

// parallel requests
var thunk1 = httpGetThunk(url1);
// processing values in order
thunk1(function(value1) {
});
});

value = res;
} else {
callback(res);
}
});
callback = cb;
} else {
cb(value);
}
}
}

Thunks
Don’t mix input with output
Easier to sequentially reason about
Unreliable Execution
Don’t handle errors
Maintain state internally
// parallel requests
// processing values in order
});
});

…but that code is complex, and usually has to be repeated for each
callback
If only we had a built in way to handle all of this….
Ok so, if we wanted to, we could solve most if not all callback
problems with a bunch of extra code

Non-Sequential Flow Unreliable Execution
Promises
Solutions?

Promises
Eventual result of an asynchronous operation
Wrappers around future values
Inherently Reliable
}Like thunks
(but better)
- We can imagine as if we already have
the result, when it arrives is irrelevant.
Handle errors

Promises
var promise = new Promise(function(resolve, reject) {
// we call resolve() on success
// we call reject() on fail
});
How do we create a Promise?
promise.then(function(value) {
// here we have the value
}, function(error) {
// here we have the error
});
How do we use a Promise?

Promises
var listener = new Promise(function(resolve, reject) {
});
We can imagine Promise returning a listener
listener.on('success', function(value) {
});
listener.on('error', function(error) {
});

Promises
});
}, function(error) {
});
- Creating a Promise returns immediately
- And we can use that promise anytime and anywhere later to
resolve it to a value
Do not mix input and output

Ok but how do Promises solve the problem of
Unreliability?

Promises are Reliable
Promise are inherently guaranteed to be resolvable once to a
single value, success OR error
Once resolved to a value, they become immutable
- their state cannot be changed
- they always resolve to that same value

resolve(1); // resolve once
resolve(2); // resolve second time (this is ignored)
reject(3); // this is also ignored
}); 
promise.then(function(result) {
console.log(result); // 1
}); 
console.log('still ' + result); // still 1
});
Resolve once

Resolve to the same value
resolve({ greet: 'MiamiJS' });
}); 
console.log(result.greet); // MiamiJS
result.greet = 'Oops';
}); 
console.log(result.greet); // Oops
});

Promises don’t get rid of callbacks.
They wrap callbacks in a reliable mechanism

resolve(res);
reject(err);
});
new Promise(function(resolve, reject) {
function httpGetPromise(url) {
return new Promise(function(resolve, reject) {
if (err) {
reject(err);
} else {
resolve(res);
}
});
});
}
How do we convert a callback utility to Promises?
1. Wrap the utility in a Promise constructor
2. Call resolve on success and reject on error

processValues(values[0], values[1]);
results.then
var results = Promise.all([promise1, promise2]);
var promise2 = httpGetPromise(url2);
results.then(function(values) {
});
Promises - Getting two values in parallel
Create promise2
and ﬁre a request
Create promise1
and ﬁre a request

});
Doesn’t mix input and output
DRY
Sequential Flow
Promises - Getting two values in parallel

Promises - Getting values in parallel (generalized)
var promises = urls.map(function(url) {
return httpGetPromise(url);
});
var results = Promise.all(promises);
processValues.apply(this, values);
});
DRY
Sequential Flow

Promise.all( 
urls.map(httpGetPromise) 
).then(function(values) {
});
Promises - Getting values in parallel (generalized)

Promise.all(
urls.map(httpGetPromise)
).then(
values => processValues(...values)
);
Promises - Getting values in parallel (generalized & ES6)

Promises are chainable
We can respond to promises in a desired
order, regardless of when they actually
resolve
- Every then call returns a Promise
Sequential Flow
- Returning a Promise from then will append it to the promise chain
- Returning a non-thenable value from then will make it the next
resolved value in the chain and proceed down the chain.
Vertical Code -> Solves “Callback Hell”

return promise2;
function(value2) {

}
function(value1) {
}
// logging value1 then value2,
// regardless of which value is 
// received first
promise1
.then(function(value1) {
})
.then(function() {
return promise2;
})
});
function() {
}
Getting two values in parallel, process them in order
// concurrent ("parallel") requests
let promise1 = httpGetPromise(url1);
let promise2 = httpGetPromise(url2); value1 received ﬁrst
1. receive value1
2. process value1
5. receive value2
6. process value2
3. proceed down the chain
4. Wait on promise2

return promise2;
function(value2) {

}
function(value1) {
}
// logging value1 then value2,
// regardless of which value is 
// received first
promise1
})
.then(function() {
return promise2;
})
});
function() {
}
// concurrent ("parallel") requests
let promise1 = httpGetPromise(url1);
let promise2 = httpGetPromise(url2); value2 received ﬁrst
1. receive value2
2. receive value1
5. Wait on promise2
6. process value2
3. process value1
4. proceed down the chain

Promises can be chained into consistent Sequential Execution
Flow, no matter the order of their internal asynchronous
operations
We choose in which order to process results,
no matter when they arrive

Requesting values in parallel but processing them in
order

urls
.map(httpGetPromise)
.reduce(function(chain, promise) {
return chain
.then(function() {
return promise;
})
.then(processValue);
}, Promise.resolve());
}); Maintain state internally
DRY
Sequential Flow

Error Handling
Errors thrown from promises are handled by the second parameter
(reject) passed to then or by the handler passed to catch
Errors thrown from promises skip all resolve handlers until a reject
handler or catch
A promise enters the rejection state when we manually call the reject
function or when a JS exception happens

Error Handling
reject(Error('an error'));
});
promise.then(function() {
// not called
}, function(err) {
err; // 'an error'
});
promise.catch(function(err) {
err; // 'an error'
});

Error Handling
2.method();
});
// not called
}, function(err) {
err; // 'Uncaught SyntaxError: Invalid or unexpected token'
});
promise.catch(function(err) {
});

Error Handling
2.method();
});
// not called
}, function(err) {
}) 
.catch(function(err) {
// Doesn’t get called because it was handled above
});

});
===
.then(_, function(err) {
});

Error Handling
try {
res = JSON.parse(res);
} catch(err) {
return cb(err);
}
cb(null, res);
});
}
function getJSON(url) {
return httpGetPromise(url)
.then(JSON.parse);
}

urls
.map(httpGetPromise)
.reduce(function(chain, promise) {
return chain
.then(function() {
return promise;
})
.then(processValue)
// err is the error from the current promise
});
}, Promise.resolve());
});
Error Handling

Ok, Promises are pretty good. Can we do better?

Generators
Pausable functions
- A special type of function that can start and
stop execution one or more times and even
never ﬁnish
Break the Run-to-Completion Semantic
When combined with Promises they further improve
the Sequential Flow of async code

Generators
Generators are functions which can be exited and later re-entered.
Their context will be saved across re-entrances.
We can push out multiple values from them

Generators
function* gen() {
yield 'pause here';
return 'I am done';
}
Calling the generator function returns an iterator.
var iter = gen();
Calling .next() on an iterator returns an object
with a value and a done ﬂag
iter.next(); // { value: any, done: boolean }

Generators
yield is a the pause/resume point of a generator
Calling .next() on the iterator provided by the generator,
runs the code within the generator from the current paused
point (yield or start of the function) to the next pause point
(yield or end of the function)
Anything passed into .next() gets pushed into the
generator as the return value from yield
Anything passed into yield gets pulled from the generator
as the return value from iterator’s .next()

function* gen(s) {
console.log(s);
console.log('yield 1 - ' + (yield 'A'));
console.log('yield 2 - ' + (yield 'B'));
console.log('end');
return 'C';
}
var iter = gen(0);
console.log(iter.next('a'));
console.log(iter.next('b'));
console.log(iter.next('c'));
console.log(iter.next('d'));
Console
{ value: 'A', done: false }
'yield 1 - b'
{ value: 'B', done: false }
'yield 2 - c'
'end'
{ value: 'C', done: true }
{ value: undefined, done: true }
0

console.log('yield 1 - ' + );
function* gen( ) {
console.log( );
console.log('end');
return 'C';
}
var iter = gen(0);
'c'
'b'(yield 'A')
console.log(iter.next('c'));
console.log(iter.next('b'));
var iter = gen(0);
console.log({ value: 'A', done: false });console.log({ value: 'A', done: false });console.log(iter.next('a'));
console.log({ value: 'C', done: true });console.log({ value: undefined, done: true });
console.log({ value: 'C', done: true });console.log({ value: 'C', done: true });
console.log({ value: 'B', done: false });console.log({ value: 'B', done: false });
iter.next('d')
return 'C';
console.log('end');
iter.next('c')
(yield 'B')
(yield 'A')
iter.next('b')
iter.next('a')
console.log( );
0s
s0
(yield 'B')
¦¦ Pause
¦¦ Pause
console.log(iter.next('d'));
Console
{ value: 'A', done: false }
0
'yield 1 - b'
{ value: 'B', done: false }
'yield 2 - c'
'end'
{ value: 'C', done: true }
{ value: undefined, done:
true }

Ok but how does that help with Async code?

Well…
What if a generator pushes out a Promise….
since generators pause and push on yield and wait for a pull so
they can continue….
and then continues running when the Promise resolves?

Promises + Generators => Control Flow Utopia
Synchronous looking Async Code

Chained requests with Generators
function *httpGetGen(urls) {
for (var i = 0; i < urls.length; i++) {
processValue(yield httpGetPromise(urls[i]));
}
}

runner(httpGetGen(['google.com', 'yahoo.com']));
processValue( );processValue( );
runner(iter, value);
promise.then
function runner(iter, prev) {
let promise = iter.next(prev).value;
if (promise) {
});
}
}
runner(httpGetGen(['google.com', 'yahoo.com']));
yield httpGetPromise(urls[i])
iter.next(prev)
promise.then
yield httpGetPromise(urls[i])
iter.next(prev)
Create promise1
and ﬁre a request
to google.com
Create promise2
and ﬁre a request  
to yahoo.com
iter.next(prev)
}
}

}
}
DRY
Sequential &
Synchronous Flow
Chained requests with Generators

var iter = httpGetGen('google.com', 'yahoo.com');var iter = httpGetGen('google.com', 'yahoo.com');
var results = iter.next().value;
iter.next(values);
});
values yield Promise.all([promise1, promise2]);
function *httpGetGen(url1, url2) {

var values = yield Promise.all([promise1, promise2]);

}
iter.next(values);
results
results.then
iter.next()
Create promise1
and ﬁre a request
to google.com
Create promise2
and ﬁre a request to
yahoo.com
Generators - Getting two values in parallel

yield Promise.all([promise1, promise2]);
Generators - Getting two values in parallel

var values = yield Promise.all([promise1, promise2]);

}
DRY
Sequential &
Synchronous Flow
Only pauses
code within the
generator

Synchronous splitting of “now” and ”later”

Generators - Getting values in parallel (generalized)
var promises = urls.map(function(url) {
return httpGetPromise(url);
});
var values = yield Promise.all(promises);
}
DRY
Sequential &
Synchronous Flow

Generators - Getting values in parallel (generalized & ES6)
function *httpGetGen(url) {
const values = yield Promise.all(urls.map(httpGetPromise));
}
DRY
Sequential &
Synchronous Flow

What about requesting in parallel but processing in
order?


processValue(yield promise1);
}
DRY
Sequential &
Synchronous Flow

var promises = urls.map(httpGetPromise);

for (var i = 0; i < promises.length; i++) {
processValue(yield promises[i]);
}
}
DRY
Sequential &
Synchronous Flow

Error Handling
Has all the beneﬁts of error handling with Promises
Can use try/catch !!!


try {
processValue(yield promises[i]);
} catch(e) {
// e is the error from the current promise
}
}
}
Error Handling
Asynchronous error handling looks synchronous

Eliminate Asynchronicity itself
Generators + Promises

Sequential Flow
Reliable
Generators + Promises
Eliminate asynchronicity as a concern
- We can imagine as if we are performing
operations synchronously

But…
We have to make our own method to combine Promises and Generators
- Many cases to handle
- Corrupts the elegancy of this approach

run(function *httpGetGen(url1, url2) {

});

Or use a library…
http://taskjs.org/
https://github.com/tj/co
https://github.com/kriskowal/q
https://github.com/petkaantonov/bluebird
https://github.com/getify/asynquence

if only we had a built in solution for this…

Async/Await
Generators + Promises, except we replace * with async and
yield with await
Stage 3 Proposal
Async function always returns a Promise
Async function can await for any value, not just a Promise

Chained requests with Async/Await
async function httpGetAsync(urls) {
processValue(await httpGetPromise(urls[i]));
}
}
DRY
Sequential &
Synchronous Flow
Native


processValue(await promises[i]);
}
}
Parallel requests with Async/Await
DRY
Sequential &
Synchronous Flow

Chaining
Since async functions return a Promise
We can chain them like Promises
We can await for them

var values = [];
values.push(await promises[i]);
}
}
async function processValues(urls) {
var values = await httpGetAsync(urls);
// ... do stuff with out values
}

Error Handling
async function httpGetAsync() {

try {
processValue(await promises[i]);
} catch(e) {
// e is the error from the current promise
}
}
}

Error Handling
httpGetAsync().catch(function(err) {
// ...
});

Sequential Flow
Reliability
Eliminate asynchronicity as a concern
- We can imagine as if we are performing
operations synchronously

Additional resources
https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/
What the heck is the Even Loop (https://www.youtube.com/watch?v=8aGhZQkoFbQ)
https://blog.risingstack.com/writing-a-javascript-framework-execution-timing-beyond-
settimeout/
https://github.com/getify/You-Dont-Know-JS
http://www.html5rocks.com/en/tutorials/es6/promises/
Promise Visualizer (http://bevacqua.github.io/promisees/)
https://ponyfoo.com/articles/understanding-javascript-async-await

Developing Async Sense

Related slideshows

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

More Related Content

What's hot

What's hot (20)

Similar to Developing Async Sense

Similar to Developing Async Sense (20)

Recently uploaded

Recently uploaded (20)

Developing Async Sense