To put it simply, the TDZ is a phase in a variable’s lifecycle where it technically exists, however it cannot be accessed or used – This phenomenon mostly applies to variables defined with the keyword let or const, but not var (And function definitions, too), thanks to the concept of hoisting (More on ‘hoisting’ in a moment – there are a few caveats, which is why I said ‘mostly’).

Let’s take a look at a contrived example to see the TDZ in action:

function myFunction() {
    console.log(x);
    let x = "Hello, world!";
}

myFunction();

The above will result in the following being logged to the JS console:

ReferenceError: Cannot access 'x' before initialization

The JS interpreter knows that x exists, however it cannot access it before it’s been initialized – x is in the temporal dead zone. Think of it this way: You’re going to make a dish that requires bread crumbs. You can see through the clear doors of the cabinet that you have bread crumbs available, but you cannot physically touch them until the doors have been opened. You know they exist, but you just can’t get to them yet. They too are in the temporal dead zone.

Let’s take a look at the same example from above, but using the var keyword to handle the variable declaration:

function myFunction() {
    console.log(x);
    var x = "Hello, world!";
}

myFunction();

The above works… Kind of. Undefined is logged to the console, indicating that x has been initialized, but has yet to be assigned any value. Interesting. Now is a good time to touch on the concept of hoisting.

In JS, hoisting is the concept where all variables (Those declared using var, let, and const) and function declarations get “hoisted” (think: “pulled to the top”) of the current scope. Note how I said declarations – NOT assignments.

Variables defined with var can be accessed before they are initialized, and they can be re-declared in the same scope, whereas variables defined with let and const cannot be accessed before they are initialized (They too are hoisted, but they are in the TDZ), and they cannot be re-declared in the same scope.

This is why in the last example from above where using var resulted in undefined being returned and not a ReferenceError like in the let example. x was declared, however it was not assigned any value, hence it was undefined.

So variables declared with the keyword var can be “used” before they’re actually assigned a value, just expect them to return undefined until they are actually assigned a value, whereas variables defined with let and const will result in a ReferenceError since they live in the temporal dead zone.

So why is the TDZ a thing when it comes to variables defined with either let or const?

Both let and const were introduced in 2015 with ES6, and the concept of the TDZ was born in order to enhance code readability and enforce some level of standardization by encouraging developers to initialize and define variables at the same time. var still exists because backwards compatibility needed to be kept in mind so older code didn’t break. As of 2024, let and const are the preferred key words to use when defining a variable.

First, what is the difference between map and forEach in Javascript?

.map() – Iterates over a collection and does something to each item and then pushes that new element to a newly created array which is then returned once each element in the provided collection has been iterated over.

.forEach() – Still iterates over a collection and does something to each item but it does not push the returned value of the action to a new array. (Think: “for each element in this array, go off an fire of an XHR and get the response and do something with it”… Have fun with all of the promises!)

Let’s recreate .map() from scratch

When writing software we take for granted what is going on under the hood in the built in methods and functions Javascript provides to us (Really any language, for that matter). By re-creating .map() from scratch will give us a better understanding of how the code is behaving in our applications. From there we can start building on that knowledge to understand more advanced topics like how the reduce function works.

Remember: .map() allows us to go through each element in a collection (array) and does something to each element (it ‘maps it’ to a new value based on the instructions we give it) and then returns an array with all the new values.

A few things stick out right away with the above breakdown:

• Our custom map function will have two parameters:
  • The input collection (array)
  • Instructions (a callback function) that we pass in
• Our custom map function will also need a way to iterate over each element – So we’ll have to employ some kind of loop to achieve this
• We’re returning a new array – at some point we’re going to have to create a new array

Ready? Here’s essentially what map is doing under the hood:

const arr = [1, 2, 3, 4, 5];

const newMap = (input, mutator) => {
  let newArr = [];
  for (let i = 0; i < input.length; i++) {
    newArr.push(mutator(input[i]));
  }
  return newArr;
};
const multiplyByTwo = (num) => {
  return num * 2;
};

const answer = newMap(arr, multiplyByTwo);

console.log(answer);

Line 1 we’re declaring a constant in memory with the label arr and assigning it the value [1, 2, 3, 4, 5].

Line 3 we’re defining a function in memory with the label newMap.

Line 10 we’re again defining a function in memory with the label multiplyByTwo.

And finally, line 14 we are declaring a constant in memory and assigning it the value to whatever the code to the right of the equals sign evaluates to – this is where we invoke/run the code above.

To the right of the equals sign on line 14 we run the newMap function and we provide it with two arguments: arr and the function multiplyByTwo.

We then create a new local execution context when we start running the newMap function where we setup our parameters:

input: [1, 2, 3, 4, 5]
mutator: (num) => { return num * 2 }

Next, we create a new empty array giving it the label newArr.

The provided array, now known as input in this local execution context, is then iterated over using a for loop. For each element in the collection, we then run the multiplyByTwo function with the input, which then returns the input number multiplied by 2 and that number is then pushed into the previously created new blank array (newArr).

Finally, once the for loop completes, the function then runs the last line of code which is to “spit out” (return) the newly created array and store that into the variable answer where we then console.log it to see it’s value.

Closing thoughts

Recreating the map function is a great exercise for newer developers because it allows you to “peel back the layers” of what’s going on under the hood in some of the code you’ve been working with for several months or years. Furthermore, doing this also gives you a better understanding of how functional programming in Javascript works and by understanding how .map() works under the hood you will have a much better understanding of how .reduce() is working which is the cornerstone of functional programming.

Object oriented programming seeks to combine data and actions that we can invoke on that data while making it easy for us programmers to switch between the two.

Consider the following scenario: We have a user and that user wants to login to our eCommerce app, browse around, place an order and perhaps leave a review for a product they purchased several weeks ago.

First, let’s take a look at a naive approach that you will see very quickly will not scale well and will lead to a lot of memory usage:

const user1 = {
    userId: "00001",
    name: "Thomas",
    displayName: "tom123",
    email: "thomas.smith@example.com",
    login: () => {
        //login business logic
        //maybe an API call, storing session info
        console.log("User has successfully logged in!")
    },
    logout: () => {
        //logout business logic
        //Another API call, removing session info
        console.log("User has successfully logged out!")
    }
}

console.log(user1.displayName) //returns 'tom123'
user1.login() //logs the user in to the app

The above code is fairly straightforward. We create an object with several properties (userId, name, etc) and assigned it the label ‘user1’ in memory. This also has a few methods attached as well: login and logout.

The object oriented ‘litmus test’ is: Can we run user1.login() and actually access both the object and the functionality that we want?

While the answer is ‘yes’ for the above sample, it has several fairly obvious issues:

What if we have 100 users, or perhaps 100,000 users or even more? Every single user object will have to have copies of those two login and logout methods and waste a lot of memory in the process. Also, what if we have to change the business logic in either of those methods sometime in the future due to some enhancements the product team wants? You would be stuck trying to individually update thousands and thousands of methods and hope for no errors along the way.

This implementation will not scale well, however at its core this is exactly what we want in terms of features – it satisfied the object oriented litmus test of ‘Can we run user1.login() and actually access both the object and the functionality that we want?’

Let’s take a look at another implementation that uses Object.create() – Object.create(), if invoked without any arguments will return a blank object. If passed an argument that is itself an object with key/value pairs, it will do something pretty interesting that gets us pretty close to our ideal solution to implement an object oriented programming paradigm in Javascript.

const userFunctions = {
  login: () => {
    //login business logic
    //maybe an API call, storing session info
    console.log("User has successfully logged in!");
  },
  logout: () => {
    //logout business logic
    //Another API call, removing session info
    console.log("User has successfully logged out!");
  },
};

const user2 = Object.create(userFunctions);

console.log(user2.__proto__, "user2 proto");

user2.userId = "00002";
user2.name = "Sam";
user2.displayName = "Sam123";
user2.email = "sam@example.com";

user2.login();

When we console.log(user2.__proto__) we get to see the magic that is going on behind the scenes. Javascript will append an __proto__ (double underscore proto, sometimes called ‘dunder proto’) to each object and it will then in turn give access to the login and logout functions. The litmus test holds true: When we call user2.login() Javascript looks to the __proto__ property when it doesn’t find the login() method immediately on user2. Once it finds it, it then invokes login() and the body of the function then runs.

Finally, we can clean this up a little further and utilize some more modern ES2015 features: The ‘new’ keyword.

The ‘new’ keyword in Javascript automates 3 key tasks for us:

1. It auto-creates an empty object and assigns it to the label ‘this’
2. It sets up a hidden __proto__ property that points to the constructor function’s prototype object that contains all of the desired functionality
3. It automatically returns the newly created object that was stored in the ‘this’ label in memory.

Let’s see it in action:

function CreateUser(userId, name, displayName, email) {
  this.userId = userId;
  this.name = name;
  this.displayName = displayName;
  this.email = email;
}

CreateUser.prototype.login = function () {
  console.log("User has successfully logged in!");
};

CreateUser.prototype.logout = function () {
  console.log("User3 has successfully logged out!");
};

const user3 = new CreateUser("00003", "Mike", "Mike123", "mike@example.com");

console.log(user3.__proto__, "user3 __proto__");

user3.login();

In this example, user3.__proto__ points to the prototype object on the CreateUser function – this happens thanks in part to the ‘new’ keyword. This functionality is made possible because when you create a function in memory, not only does Javascript save the function body, but it also creates a ‘hidden’ object that you can append key/value pairs to. This concept is sometimes referred to as a “function object combo”.

Javascript takes the above concepts even one step further by implementing classes, however that topic is better left for another article for another time. Thanks for reading and hopefully you’ve gained a better understanding of how the ‘new’ keyword is working under the hood!

If you’re a less experienced front end developer and are looking to up your JavaScript game, forcing yourself to create a few Angular apps is a great way to really level up your JS skill set. React and Vue do a great job at abstracting things away so some things that happen just seem like magic. Angular still has abstractions however not to the extent of the other two so you’re forced to roll up your sleeves and up your JS game. (This is really just me saying the learning curve for Angular is more demanding that any other front end framework.)

Angular ships with RxJS and it’s a complete paradigm shift in that you no longer simply rely on fetch() or axios.get() to handle your HTTP requests in your app. RxJS instead allows us as developers to subscribe to a data stream and listen to it for any changes while the subscription is active. To be fair, you can implement RxJS in either a React or Vue app, but neither ships with it out of the box so it’s up to you the install it as a dependency and use it (Convention over configuration… Remember?)

Subjects and BehaviorSubjects are observables that can emit their values to multiple observers via subscriptions. On the surface we’re almost inclined to think that both a Subject and a BehaviorSubject do the same thing, but the differences are subtle and can make a pretty big impact on your application.

In simple terms: A Subject does not need to have an initial value when being created but a BehaviorSubject requires an initial value when being created. Therefore, a Subject will only emit upcoming values, whereas a BehaviorSubject will emit one previous value and all upcoming values.

Let’s set the stage for a pretty common example front end developers handle on a routine basis: showing or hiding a modal to let the user edit settings. As you can imagine, this is a good use case for a BehaviorSubject because we’ll want to set the initial value of “showModal” to “false”.

// src/app/services/modal.service.ts

import { BehaviorSubject } from 'rxjs';

export class ModalService {
  showModal = new BehaviorSubject<boolean>(false);

  toggleModal() {
    this.showModal.next(!this.showModal.value);
  }
}

Had we not passed in a boolean value to the BehaviorSubject’s constructor, TypeScript would have immediately given us an error indicating that one argument was expected, but we’ve given it 0.

The above example sets up an Angular service that we can then import into any other component and utilize the toggleModal() method. Any subscriptions to this observable therefore will receive an initial value of “false” since BehaviorSubjects allow us to track and initial value and any subsequent changes in the future.

On the other hand, a Subject does not require an initial value. In sticking with the modal example from above, a good parallel use case for a Subject would be if upon the user opening a modal in the app we want to display a form containing the app’s settings that they can modify and then save. Let’s take a look:

// src/app/services/settings.service.ts

import { Subject } from 'rxjs';
import { HttpClient } from '@angular/common/http';

export class SettingsService {

  appSettings = new Subject<Settings>();

  constructor(private http: HttpClient) {}

  getAppSettings() {
  this.http.get<Settings>('https://www.myapp_api.com/settings')
    .subscribe((settings: Settings) => {
      console.log(settings, 'Settings received from API call.');
      this.settings.next(settings);
    )};
  }

}

Sure, there’s a little more code than the previous BehaviorSubject example but most of it is simply boiler plate code in order to set things up. The key takeaway here should be that when we create a new Subject, we do not have to supply its constructor method with an argument to set the initial value upon creation. We only have to indicate what kind of value will be occupying it in the future, which in this case is an object of type “Settings”.

We’ve defined a getAppSettings() method that we can again import into any other component and fetch our user’s app settings from the back end and then once the request comes back we will push the new value via the next() method and any subscriptions made will finally receive their first value. We will then have access to the app settings, now stored with the label appSettings, be it an object of settings or an array.

So what’s the tl;dr version of all of this? Pretty simple, actually:

Use a BehaviorSubject if you need an initial value (The modal example above is a really good example) and use a Subject if you do not need an initial value.

From MDN, a closure is as follows:

A closure is the combination of a function bundled together (enclosed) with references to its surrounding state (the lexical environment). In other words, a closure gives you access to an outer function’s scope from an inner function. In JavaScript, closures are created every time a function is created, at function creation time.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures

Essentially, we can think of a closure as a backpack that every function gets whenever it is defined. The contents of said backpack are dependent on where the function was defined – this is also known as its scope. This is what we mean when something is lexically scoped. In this backpack we will find the surrounding function’s variables, which will allow the inner function (the one that is carrying the backpack) to have access to the outer function’s scope/variables even after it’s finished executing. We can really start to leverage this feature of JavaScript when we return a function from another function.

Let’s take a look at a really basic example to get a better understanding at how this concept works in practice:

function outerFunc() {
  let counter = 0;

  return function innerFunc() {
    console.log(`The value of counter is: ${counter}`);
    counter++;
  };
}

const runnerFunc = outerFunc();

runnerFunc();
runnerFunc();
runnerFunc();
runnerFunc();
runnerFunc();
runnerFunc();

And the output that’s logged to the console is:

The value of counter is: 0
The value of counter is: 1
The value of counter is: 2
The value of counter is: 3
The value of counter is: 4
The value of counter is: 5

Line 6 from the code example above (Not the console.log output) is extremely important – the inner function is incrementing a variable that was defined in the outer function’s scope. When running functions, we’re used to them not being able to persist the variables/state from its previous execution context (the last time it was run), but somehow in this example the inner function was still able to access variables that belonged to the outer function’s scope even after it was finished running! Enter the concept of closures!

We can do some really interesting things with this newly found knowledge. Let’s take another look at a custom made generator function that we can pull values from one at a time. This is a big paradigm shift in that we normally iterate over a collection of objects and get the value one at a time that way using a tried and true for or while loop. Let’s have a look:

function countUpUntil(x) {
  let counter = 0;
  function next() {
    if (counter <= x) {
      return { value: counter++, done: false };
    }
    return { value: undefined, done: true };
  }

  return { next };
}

const iterator = countUpUntil(5);

console.log(iterator.next());
console.log(iterator.next());
console.log(iterator.next());
console.log(iterator.next());
console.log(iterator.next());
console.log(iterator.next());
console.log(interator.next());

And let’s have a look at the output from the console:

{ value: 0, done: false }
{ value: 1, done: false }
{ value: 2, done: false }
{ value: 3, done: false }
{ value: 4, done: false }
{ value: 5, done: false }
{ value: undefined, done: true }

Now we’ve created a function in such a way that will only allow us to run it a certain amount of times! We can use this method to enable us to “pull” from a collection each time the function is run as opposed to us traversing the entire collection using a traditional for/while loop – an incredible paradigm shift that paves the way for concepts like observable streams, generator functions, and iterator functions, all of which are significant building blocks in the JavaScript ecosystem.

In the above code example, we again have an inner function, this time called next, that is accessing the variable with the label counter that was defined in the outer function’s execution context. In fact, we reference counter twice – we perform a conditional to see if counter is less than or equal to x (the number we want to ‘count’ up until), and if the conditional is true, we then return an object that contains the value of count after it’s been incremented by 1, as well as a boolean letting us know whether or not the stream is done. When the conditional returns false, we get an object back with a value of undefined, and a truthy value for done letting us know the stream has finished giving us results. We can then implement logic elsewhere in our program to check for the truthy value.

Essentially, each opening bracket or brace needs to have a corresponding closing bracket or brace.

First, let’s take a look at the code in its entirety:

const isValid = (s) => {
    const remaining = [];
    const legend = {
        "(" : ")",
        "{" : "}",
        "[" : "]",
    };
    
    for (let i = 0; i < s.length; i++) {
        if (s[i] === "(" || s[i] === "{" || s[i] === "[") {
            remaining.push(s[i])
        } else if (legend[remaining.pop()] !== s[i]) {
            return false;
        }
    }
    return remaining.length ? false : true;
};

isValid("()[]{}");

We begin by defining an empty array that is going to serve as a “pseudo stack” in which we are pushing/popping elements from as we traverse the given string. We also define a legend object, which is simply a key/value collection of each opening bracket/brace and its associated closing element.

We will utilize a traditional for loop that will traverse the input string and within each iteration of the loop we will perform two checks:

1. If the current character of the input string s[i] is equal to any opening bracket/brace we will push it into the remaining array.
2. Else, if the last character from the remaining array DOES NOT equal the current character, we return false;

If the second condition is never encountered, we reach the end of the string and then do one final comparison where we look to see if there are any remaining elements in the array. If so, we return false. This last check essentially checks for any orphaned brackets that might have resulted from the input string be an odd length.

One possible alternative solution to this last check is to do the odd check at the very start of the function and immediately return false if the length is determined to be odd. If this is the case, we can safely assume that at least one bracket/brace doesn’t have a valid closing bracket/brace. It would look like this:

const isValid = (s) => {
    if (s.length % 2 !== 0) return false;
    const remaining = [];
    const legend = {
        "(" : ")",
        "{" : "}",
        "[" : "]",
    };
    
    for (let i = 0; i < s.length; i++) {
        if (s[i] === "(" || s[i] === "{" || s[i] === "[") {
            remaining.push(s[i])
        } else if (legend[remaining.pop()] !== s[i]) {
            return false;
        }
    }
    return true;
};

isValid("()[]{}");

I opted to create a helper function that takes an object that contains the word itself, as well as the count – or frequency – that each word appears. The function simply returns a string based on whether or not certain conditions are made. For example, if the word count is less than or equal to 4, it will return the string “small”. We can then use that to set the fontSize to “small”. Let’s take a look at the code:

import React from "react";
import "./word-cloud.styles.css";

const WordCloud = () => {
  const words = [
    { word: "car", count: 3 },
    { word: "electric", count: 8 },
    { word: "engine", count: 5 },
    { word: "motor", count: 11 },
    { word: "brake", count: 1 },
  ];

  const applyStyling = ({ word, count }) => {
    if (count <= 2) {
      return "x-small";
    } else if (count <= 4) {
      return "small";
    } else if (count <= 6) {
      return "medium";
    } else if (count <= 8) {
      return "large";
    } else if (count >= 9) {
      return "x-large";
    } else {
      return "medium";
    }
  };

  return (
    <div className="main-div">
      {words.map((word, index) => (
        <li key={index} className="word-list-item">
          <p style={{ fontSize: applyStyling(word) }}>{word.word}</p>
        </li>
      ))}
    </div>
  );
};

export default WordCloud;

I opted to go with in-line styling for this specific example instead of creating many classes that each set the font-size property to the proper values. If you wanted to implement a CSS class-based implementation, instead of a style attribute, you’d utilize the className attribute, and assign the returned value from the applyStyling function to that.

Two of the main building blocks when creating a Vue component are computed properties, as well as watchers. Initially, both seem to be very similar, but a few quick examples of their suggested use cases will quickly clear up what a computed property is best suited for, and what a watcher is best suited for.

First, per the Vue documentation, let’s check out their definitions:

Computed Property

A computed property is used to declaratively describe a value that depends on other values. When you data-bind to a computed property inside the template, Vue knows when to update the DOM when any of the values depended upon by the computed property has changed. This can be very powerful and makes your code more declarative, data-driven and thus easier to maintain.

Vue.js documentation

Watcher

While computed properties are more appropriate in most cases, there are times when a custom watcher is necessary. That’s why Vue provides a more generic way to react to data changes through the watch option. This is most useful when you want to perform asynchronous or expensive operations in response to changing data.

Vue.js documentation

One of the best examples to show what a computed property is best used for is to create a method that formats names that you get from either props that are being passed in, or fetched from an external API call. Let’s take a look at a simple example where we rely on an API response to get the names of all super heros:

<!-- COMPUTED PROPERTY EXAMPLE -->
<template>
  <div v-if="formattedSuperHeroNames.length">
    <li v-for="hero in formattedSuperHeroNames" :key="hero.id">{{ hero.heroName }}</li>
  </div>
</template>

<script>
export default {
  name: "Computed",
  data() {
    return {
      superHeros: [],
    };
  },
  async mounted() {
    try {
      response = await fetch("https://akabab.github.io/superhero-api/api/all.json");
      if (response.ok) {
        this.superHeros = await response.json();
      }
    } catch (error) {
      console.log(error);
    }
  },
  computed: {
    formattedSuperHeroNames() {
      let formattedNames = [];
      this.superHeros.forEach((superHero, index) => {
        const name = superHero.toUpperCase();
        formattedNames.push({ heroName: name, id: index });
      });

      return formattedNames;
    },
  },
};
</script>

Notice how within the template of the Vue component that formattedSuperHeroNames is being referenced, however it isn’t defined within the data property as we’d normally expect. Instead it is actually a function – which also shares the same name – that is defined within the computed object. We can treat any method that is defined within the computed property as if it was a normal property defined within the data property!

The above example simply hits an API once the component is mounted and then once the results are retrieved Vue knows to run formattedSuperHeros() which will iterate over the API response and make each super hero name all upper case letters. Imagine if you had an API where it returned a list of employees and each employee had their first name and last name split between two fields and you wanted to combine them – a computed property would be a great way at achieving this.

What about a watcher? A watcher is different than a computed property in the sense that a watcher wacthes another property and then when it changes it will perform some kind of side effect. A really simple example would be: Keep track of the number of clicks. Once the number of clicks reaches 5 THEN make an API call.

Let’s see how this would work:

<!-- WATCHER EXAMPLE -->

<template>
  <div>
    <button @click="incrementClickCount">Click me!</button><br />
    Number of clicks: {{ numberOfClicks }}
  </div>
</template>

<script>
export default {
  name: "Watcher",
  data() {
    return {
      numberOfClicks: 0,
    };
  },
  methods: {
    incrementClickCount() {
      this.numberOfClicks++;
    },
  },
  watch: {
    numberOfClicks(newValue, oldValue) {
      if (newValue === 5) {
        //HIT AN API END POINT!
      }
    },
  },
};
</script>

One important thing to note is that a watcher MUST have the same name of the property that it is watching over. If it does not share the same name, it will never be invoked and instead just sit idle in your code. Vue also gives us access to both the newValue and oldValue of the property that we are watching, which allows us to more easily implement conditional logic as shown in this example. We’re waiting for the user to click the button exactly 5 times, and then once that happens we hit an API. A good example of this would be for some kind of error logging functionality where we want to see if the user is experiencing some kind of UI issue and is repeatedly clicking/tapping a button over and over again.

tl;dr version

A computed property is best suited for formatting/interacting with a pre-existing data property or prop that has been passed into the component via a parent component, but side effects aren’t desired (Nor should they be introduced via a computed property). A watcher is best suited for when a side effect should happen in response to a certain property/prop changing or reaching a certain value.

JavaScript code does not wait for a task to finish as it works through its thread of execution. As a result, we can say that JavaScript is a synchronous language – it never goes back up when executing code.

A quick refresher on Promises

A few months back I wrote this post about Promises and went into detail about what’s happening behind the scenes when a Promise is first created. Essentially, when created, a promise will immediately return a plain JavaScript object with a few blank/empty properties. Those properties being value, onFulfillment[], onRejection[].

value is immediately undefined.

onFulfillment is an empty array – we use the .then() method to push any functions we want to execute when the asynchronous task has completed successfully.

onRejection is an empty array – We use the .catch() method to push any functions we want to execute when the asynchronous task has failed and caused an error.

Thanks to JavaScripts microtask queue in conjunction with the call stack, the functions that are pushed to either onFulfillment or onRejection will not run until the call stack is empty.

A Traditional Promise Chain Example

Let’s take a look at a traditional Promise chain in which we will use node-fetch to hit an API and simply return its result to the console:

import fetch from "node-fetch";

fetch("https://cdn.jsdelivr.net/gh/akabab/superhero-api@0.3.0/api/id/1.json")
  .then((response) => {
    return response.json();
  })
  .then((data) => {
    console.log(data);
  })
  .catch((error) => {
      console.log(error)
  })

It’s somewhat verbose, isn’t it? But taking into account what was discussed above about what each .then() call is doing, and what each .catch() call is doing, along with the interaction between the microtask queue and the call stack, it’s really not too difficult to unpack what’s going on.

We invoke fetch() with the API URL as its argument, we then define two arrow functions to push into the microtask queue: The first function (The argument of the first .then() call) parses the response as JSON, the second function (the argument for the second .then() call) receives that parsed JSON and outputs it to the console. Finally, in the event of an error, we created a function that will simply take the error and display it to the console (This function is the argument given to the .catch() method).

Not bad – Roughly 12 lines of code, but there is an even easier way: Enter async/await

Async/Await

In 2017 (ES8) async/await was introduced into the language spec and one of the main goals behind this feature is to make writing, maintaining, and understanding asynchronous code a little easier. Let’s replicate the above example – we’ll hit an API, parse the response, and finally display it to the console.

const heroResponse = await fetch("https://cdn.jsdelivr.net/gh/akabab/superhero-api@0.3.0/api/id/1.json");
const heroData = await heroResponse.json();
console.log(heroData);

Thanks to async/await, In just three lines of code we did what used to take us about a dozen. The await keyword is taking what would have previously been assigned to the promise’s undefined value and instead assigns it to whatever is to the left of the equals sign (assignment) – It’s simply a further abstraction to the traditional .then() promise chain.

What about error handling?

This is a good question. Usually when implementing the new async/await API, you’ll also want to pair it with a try/catch block. A try/catch block literally means “First, try running this code. If for some reason you encounter an error, catch it, and then run this code with whatever error you caught as an argument”.

Let’s add it to the above example:

  try{ 
    const heroResponse = await fetch("https://cdn.jsdelivr.net/gh/akabab/superhero-api@0.3.0/api/id/1.json");
    const heroData = await heroResponse.json();
    console.log(heroData);
  } catch (error) { 
      console.log(error)l
  }

What about the keyword ‘async’?

Another good question. In the above two async/await examples the async keyword was not even used once. So why is it called async/await then? If the code we’re writing is in the global execution context, then it is implicitly async code and we can use await without it.

However, if we were to take the above code and create a new function so we can use it over and over again, then we would have to use the async keyword. Here’s how we would bring it all together:

const getHeroInfo = async () => {
  try {
    const heroResponse = await fetch("https://cdn.jsdelivr.net/gh/akabab/superhero-api@0.3.0/api/id/1.json");
    const heroData = await heroResponse.json();
    console.log(heroData);
  } catch (error) {
    console.log(error);
  }
};

Notice at the top of the arrow function’s definition (Literally in between the equals signs and the set of open/close parenthesis where we’d define our parameters) the keyword async is being used. This tells JavaScript that the code within this function is asynchronous and to treat it accordingly.

Even in 2023, about 5 years after async/await was introduced to the language, you will still see a mix of both .then() chaining and async/await syntax in existing code bases. For the most part, it boils down to personal preference, as well as what the rest of your team is doing/comfortable with.

According to the official Javascript language spec, a promise is:

“…a proxy for a value not necessarily known when the promise is created. It allows you to associate handlers with an asynchronous action’s eventual success value or failure reason. This lets asynchronous methods return values like synchronous methods: instead of immediately returning the final value, the asynchronous method returns a promise to supply the value at some point in the future.”

Still confused? Put a different way – A javascript promise is a plain old javascript object that represents a future value so the rest of the code can still be carried out in a synchronous manner. Javascript is non-blocking – this means that it will not wait for a task to complete before moving on to the next line. Instead of waiting for the asynchronus task to complete, the promise object acts as a “place holder” to represent the future value.

The promise object contains several crucial key/value pairs:

Value – Immediately is undefined and upon successful fulfillment of the operation, value will contain the resulting data that has been returned.

OnFulfillment – Initially, an empty array that will serve as a “repository” of methods to invoke if and when the promise has resolved successfully.

OnRejection – Initially, an empty array that will again serve as a “repository” of methods to invoke if and when the promise has not resolved successfully.

So in summary, the promise object will immediately look like this:

{ value: undefined, onFulfillment: [], onRejection: [] }

Where does .then() and .catch() come into play?

One common misconception is that .then() and .catch() are some kind of magical methods that will allow the code within the parenthesis to somehow to run sometime in the future. Though technically true in that they do allow code to be run in the future, the way both methods work under the hood are somewhat simplistic in nature so it seems like magic to us.

.then() and .catch() are essentially pushing the function that we define within the parenthesis into the respective empty arrays on the newly created promise object this way they can be invoked once the time comes. (More on this in a bit)

So if we write myPromise.then(response => console.log(response))

We are more or less doing the following:

const futureFunction = (response) => console.log(response)
myPromise.onFulfillment.push(futureFunction)

And if we write myPromise.catch(response => console.log(response))

We are more or less doing the following:

const futureFunction = (response) => console.log(response)
myPromise.onRejection.push(futureFunction)

Once the promise has resolved the value is the inherently passed in to each provided function – in the above example we’re calling the value “response”. A lot of times in production code when making a fetch request to an API you will see a conditional checking if response.ok – this means that we’re checking to see if the HTTP status code we received back from the server is 200 (technically 2xx).

When do the functions we provide to .then() and .catch() actually run?

This can probably be its own blog post on its own given how in depth you can get with this topic. The functions we provide to .then() and .catch() don’t just run whenever we finally get a response back from whatever task we initially started. Remember: Javascript is non-blocking so once it’s done with a line of code that’s it – it’s not going to suddenly go back up several lines in the execution context and re-run lines of code because we got a response back from an API call.

Enter the concept of the call stack, the event loop, and the microtask queue.

While we are executing our Javascript code we’re constantly pushing and popping things from the call stack – We will start in the global execution context and then as we enter functions we find ourselves diving deeper and deeper into the execution contexts of those same functions and therefore pushing more and more onto the call stack. Remember: The call stack is like a stack of dishes in your sink – When you go to wash the dishes you’re going to take the dish that is at the top of the stack first and start washing it. This is know as Last In First Out, or LIFO for short. As we finish running those functions we pop them off of the call stack… And finally, when we’re done running all of the code in the Javascript file (the global execution context) we pop global off of the call stack as well and it’s finally empty – and then the magic can start.

The event loop essentially keeps checking to see if the call stack is empty. Once the call stack is indeed empty it will then allow any finished asynchronous tasks that have finished to then run – When a promise is finally resolved or rejected the contents of either the onFullfillment or onRejection arrays are then moved from the microtask queue onto the call stack via the event loop to finally be executed.