In the following code:
const fs = require('fs');
const promisifiedReadfile = require('./promisifiedReadfile');
// Here we use fs.readfile() and callback functions:
fs.readFile('./file.txt', 'utf-8', (err, data) => {
if (err) throw err;
let firstSentence = data;
fs.readFile('./file2.txt', 'utf-8', (err, data) => {
if (err) throw err;
let secondSentence = data;
console.log(firstSentence, secondSentence);
});
});
function readFiles() {
let firstSentence = promisifiedReadfile('./file.txt', 'utf-8');
let secondSentence = promisifiedReadfile('./file2.txt', 'utf-8');
console.log(firstSentence, secondSentence);
}
console.log("test")
readFiles();
From this exercise (I edited the code a little bit)
Hey! Yes, fs.readFile is asynchronous, so it prints after readFiles() which is not asynchronous in your example.
You can add async/await to readFiles() to make it asynchronous (it will not return Promise { <pending }).
console.log("test") will always appear first, before the asynchronous actions.
2 Likes
Highly recommend this book’s chapter on async
# You Don't Know JS: Async & Performance
# Chapter 1: Asynchrony: Now & Later
One of the most important and yet often misunderstood parts of programming in a language like JavaScript is how to express and manipulate program behavior spread out over a period of time.
This is not just about what happens from the beginning of a `for` loop to the end of a `for` loop, which of course takes *some time* (microseconds to milliseconds) to complete. It's about what happens when part of your program runs *now*, and another part of your program runs *later* -- there's a gap between *now* and *later* where your program isn't actively executing.
Practically all nontrivial programs ever written (especially in JS) have in some way or another had to manage this gap, whether that be in waiting for user input, requesting data from a database or file system, sending data across the network and waiting for a response, or performing a repeated task at a fixed interval of time (like animation). In all these various ways, your program has to manage state across the gap in time. As they famously say in London (of the chasm between the subway door and the platform): "mind the gap."
In fact, the relationship between the *now* and *later* parts of your program is at the heart of asynchronous programming.
Asynchronous programming has been around since the beginning of JS, for sure. But most JS developers have never really carefully considered exactly how and why it crops up in their programs, or explored various *other* ways to handle it. The *good enough* approach has always been the humble callback function. Many to this day will insist that callbacks are more than sufficient.
But as JS continues to grow in both scope and complexity, to meet the ever-widening demands of a first-class programming language that runs in browsers and servers and every conceivable device in between, the pains by which we manage asynchrony are becoming increasingly crippling, and they cry out for approaches that are both more capable and more reason-able.
While this all may seem rather abstract right now, I assure you we'll tackle it more completely and concretely as we go on through this book. We'll explore a variety of emerging techniques for async JavaScript programming over the next several chapters.
But before we can get there, we're going to have to understand much more deeply what asynchrony is and how it operates in JS.
## A Program in Chunks
show original
1 Like
Title sounds interesting, I’ll check it out surely!
