Forem: Veronika Šimić

Trouble at the docks - part 2

Veronika Šimić — Mon, 06 Feb 2023 05:35:15 +0000

It’s been a while since your last encounter with Don Porto. The smell of fish still in the air, but there are some questions left unanswered. Like what is all that output we got in the console? And how does the image actually get built? And how are you going to send this amazing application of yours to your friend in Guadalajara?

You go down to the docks in hope to find Don Porto again. 🐟

Don Porto

Hey, don Porto, it’s me, your favorite student.

Who?

You know I made that amazing application and you packaged it for me. It’s called masterpiece.

Ah yes, the annoying one, now I remember. What do you want?

I was wondering if you could tell me more about how images are built.

Ah... as I said annoying. I hope you remember that Docker is a platform for building, running and shipping applications. It’s very helpful in situations like yours. The code works on your machine but not on your friends. Tell me, how did you explain to your friend how to run this amazing application of yours.

Well I wrote him a message:
1. clone the repo from my github account 💻
2. install node 💡
3. run npm install for dependencies ⌛
4. run node index.js and voila, magic happens 🎉

You know they speak Spanish in Guadalajara? No wonder he got confused... So, even though this is a pretty simple app there is still a possibility of doing something wrong in any of these steps. Now imagine if you had a much better app then yours.

Ok, I'll try. I don’t think such a thing exists.

Ha! On really good applications this would be even many more complicated, you would have to go through a lot of more than just four steps. There would be a lot of documentation, and maybe you would have to do this on many computers, not just one.

Yes, and who has the time? I have to go home and have dinner with my cat. She was pretty angry the last time.

Yes I can see all the scratch marks. Anyway... wouldn’t it be great that your friend doesn't have to do any of these steps? We just send him a file and he can run the whole application with everything already configured?

Well, yes I guess I would have much more friends then.

No, no, you wouldn’t. That’s what Docker does for us. We package all of our code and instructions on how to run this code, into a single file and then when someone downloads it there is no chance of error. If it works on our machine it will work on theirs also.

Aha. I get it. And what about building the image? What exactly happens?

Building masterpiece 🚧

Let's start with our Dockerfile, step by step.

FROM node:16-alpine

Run this command and watch what happens.

docker build -t masterpiece .

As you can see the build was very fast because we only had one command. We also used a very small linux base image, alpine. There are a lot of images available at the Docker Hub and you should choose the one that suits your needs. A smart person would now ask why do we even need the base image?

What? Oh, yes why do we need...

Save it. If I were to tell you to install Chrome on a machine that doesn't have an OS. What would you do?

Well, I would... I would...

You would first need to install some OS, then go to the default browser, search for Chrome, download it and execute it. You can think of base image as a starting point for our custom image. Let's see what we have inside of it.

Ok, I will run this container interactively with shell inside of it. Then I can do ls to see all the files inside.

docker run -it masterpiece sh

Heeeey, where are my files? I have much more than this.

Calm down. We haven't copied your precious files yet. Add the COPY . /app or WORKDIR /app and COPY . . commands to your Dockerfile, then build the image again.

FROM node:16-alpine
WORKDIR /app
COPY . .

Aha, so I can use an absolute or relative path. Cool.

As you can see the build took a little bit longer this time. Now when you run ls inside the container shell you will see all of your files.

Great. But wait. My awesome application is still not running. I mean I am running a shell script inside of the container but where is my masterpiece?

Ah, you noticed that, didn't you. So in order for us to run your "masterpiece" we have to specify the command to execute when running our container.

So, something like this?

docker run masterpiece node index.js

Yes, but this is not very practical. Each time we run the container we have to specify the command to execute. We could add an additional command to our Dockerfile.

Is that what CMD ["node", "index.js"] does?

Yes, this fish air is doing you good. Add that to your Dockerfile and build the image again.

FROM node:16-alpine
WORKDIR /app
COPY . .
CMD ["node", "index.js"]

Now when you run the container your app is starting.

Ok this is great but as I heard it on the streets the CMD command can be overwritten. Each time I start the container I can specify a command to run instead of the CMD command.

Well I don't know about these streets you are visiting, but yes you are right someone could still do this docker run masterpiece echo Fluffy

Awwwww... you remembered my cat's name. 😊

It's on your forehead remember? If you want to stop this from happening instead of using CMD you can use ENTRYPOINT ["node", "index.js"]. But, let's leave the CMD for now.

I have another question. If I send this file to my friend he could delete some files inside that container. I don't think that's very smart. Can we prevent this?

Oh, yes we wouldn't want to mess up this perfection. You can specify a user inside your Dockerfile. Now your Dockerfile should look something like this:

FROM node:16-alpine
RUN addgroup friends && adduser guadalajara -S -G friends guadalajara
USER guadalajara
WORKDIR /app
COPY . .
CMD ["node", "index.js"]

You build the image again, run the container and then execute whoami inside the shell to see the current user.

Ok and now I can't create a new directory or delete anything. Great.

You can also specify the port on which your application is running. By adding EXPOSE 3000 to your Dockerfile you aren't actually exposing the port, it's just part of the documentation.

Aha, yes I remember to actually expose the port I have to run docker run -p 3000:3000 masterpiece .

Yes, great. You may have noticed that each time we build our image we get the output in the console. This shows us that our image is built layer by layer. Can you guess why this is better?

Is it because when we change something only that part and all the parts after that will get rebuilt?

Ding, ding, ding we have a winner. Let's check the actual history of how our image was built. Run this command:

docker history masterpiece

We read it bottom to top. I highlighted the part which comes from alpine base image, so that you don't get confused. You can clearly see how the image was built. We built our custom image on top of the base image. If you want to see all the images you currently have just run docker images or docker image ls

Shipping our image 🚢

I don't have much time, it's almost dinner. I can feel Fluffy is getting angry, so tell me how do I share this image?

Yes, we wouldn't want to upset him. First create a repository on Docker Hub called fluffy. After that we have to tag your masterpiece.

docker image tag masterpiece fluffy/masterpiece:latest

Make sure the tag has the same name as the repo to which you are pushing. Then run docker login, sign up with your credentials and push the image to Docker Hub.

docker push fluffy/masterpiece:latest

Your image is now on Docker Hub and anyone can pull it with docker pull fluffy/masterpiece:latest. Although I don't see why anyone would...

Thank you don Porto. Can we talk next time about containers? And what about volumes? And...

Ok, ok I get it you are annoying. Now go home to Fluffy. 🐱

The ultimate guide to variables in JavaScript

Veronika Šimić — Mon, 30 Jan 2023 14:14:08 +0000

It was a day of potato harvest. Working on the field all day isn't easy and you are ready to go home to your family. You sit down, sigh deeply, and enjoy a bit of fresh air.

Suddenly the king's herald appears.

"Hear ye, hear ye! His Majesty the King hereby declares that a new tax on all peasants, merchants and traders within the kingdom shall be imposed. The revenue from this tax shall be used to fund the king's big appetite. All merchants and traders are required to pay this tax in full, and failure to do so shall result in severe penalties."

Quickly you collect all potatoes and make a run for it. No way you are giving the potatoes you stole, fair and square, to some king. You end up in the woods and hide behind a big bush thinking:

"It would be nice to store all of this potatoes somewhere safe."

And just like that you hear a voice:

Hey you, those are some nice looking potatoes. Would you like me to take care of them?

Var

"Who is that? Show yourself before I throw one of my potatoes on you."

My name is var. I have been storing various things for peasants and kings for 20 years. But now it seems that the whole world has forgotten about me.

"Hmm... I'm kind of tired from carrying these potatoes. It would be nice to rest. Ok, var store them."

var potatoes = 20;

Thank you for this opportunity. Now if you want to retrieve them, just say the magic word console.log()

"Is there a way to protect them even more? It took me a long time to steal them."

How about this?

{
  var potatoes = 20;
}

console.log(potatoes);

Output

"So, no? You ain't block scoped? How am I going to protect them then?"

I may not be block scoped but I am function scoped.

function protectPotatoes() {
  var potatoes = 20;
}

console.log(potatoes);

Now, no one can access them. Even our great queen and king could not get them.

Output

ReferenceError: potatoes is not defined

In fact, I can even give them decoy potatoes and shadow your original potatoes.

var potatoes = 10;

function protectPotatoes() {
  var potatoes = 20;
}
console.log(potatoes);

Output

"Ha! Does this happen because potatoes are globally scoped when they are defined outside the function? And now when they are inside the function, that is they are function scoped, they are only available inside that function block?"

Well, for a peasant, you sure do know a lot of JavaScript. For that, I'm going to show you what else I can do with your potatoes.

console.log(potatoes);
var potatoes = 20;

Output

undefined

You see, even though we haven't met yet, I believed in you. I knew you were going to bring me some potatoes. The way I see it is this:

var potatoes;
console.log(potatoes);
var potatoes = 20;

"Aha. So you are hoisted at the top? I can just declare that there are going to be some potatoes in the future. I don't need to assign anything yet? But there's just one thing I have been wondering. What if someone does this: "

var potatoes = 20;
var i = 1;

if (i > 0) {
  var potatoes = 0;
}

console.log(potatoes);

Well, yes, now your potatoes aren't safe anymore. How are you only eating potatoes if you know so much JavaScript?

Output

"I think this isn't a very good trait of yours. You are quirky and untrustworthy."

What did you just say to me? Say goodbye to your precious potatoes.

var potatoes = 20;
var potatoes = 0;
console.log(potatoes);

Output

"Noooooooo, my potatoes. No wonder no one likes you. You can even redeclare."

Tell you what, if you can guess what's going to happen now, I'm going to bring your potatoes back.

console.log(potatoes);

function getPotatoes() {
  var potatoes = 20;
  console.log(potatoes);
}

getPotatoes();
console.log(potatoes);

"Well, I guess that I am having french fries for dinner! The correct answer is 20."

Ha. WRONG!!! What you get is nothing. You see, before the function is called, the first console.log(potatoes) is executed. But since there are no potatoes yet, we get an error. Also, what are french fries?

Output

ReferenceError: potatoes is not defined

"Like I would tell you... thief!!"

Let 🌰

As you walk through the woods, defeated, hopeless and potatoless, you come across a tree of chestnuts.
After fighting a squirrel, you are faced with the same problem. A second voice appears:

Hail fellow, well met. Nice chestnuts you got there. What are you going to do with them?

"Who are you? var, is that you again? Get away from me!"

Oh easy there, my friend. I am not var. My name is let. I am var's cousin. I can store those chestnuts for you:

let chestnuts = 50;

"var did the same thing before she stole my potatoes. Now I am forced to eat chestnuts for dinner. I don't know if you noticed but I am not a squirrel."

Really? And what about those two very long front teeth? It's unfortunate that you ran into var. But I can assure you that I am different.

"Oh, really? And why should I trust you?"

Because I can protect your chestnuts:

{
  let chestnuts = 50;
}

console.log(chestnuts);

Output

ReferenceError: chestnuts is not defined

"Now this is what I want. So you are block scoped, unlike that malicious var. What else can you do? Can you hide them inside a function?"

Well, yes that runs in our family.

function protectChestnuts() {
  let chestnuts = 50;
}

console.log(chestnuts);

Output

ReferenceError: chestnuts is not defined

"And what about decoy chestnuts? Can you do something like this?"

let chestnuts = 10;

function protectChestnuts() {
  let chestnuts = 50;
}
console.log(chestnuts);

Yes, I've also inherited this from var.

Output

"And what about this?"

console.log(chestnuts);
let chestnuts = 20;

Well, no I can't do that. I have to be sure there are chestnuts before I can show them to you. I am not as gullible as var.

Output

ReferenceError: Cannot access 'chestnuts' before initialization

"Aha. I guess you also don't have a problem with this:"

let chestnuts = 50;
let i = 1;

if (i > 0) {
  let chestnuts = 0;
}

console.log(chestnuts);

Don't worry, even if someone has number 10, they won't be able to steal your chestnuts, I am block scoped, as you said.

Output

"There's got to be something wrong with you."

Well, yes there is, but I don't like talking about it. Since your teeth remind me of Mary, I'll tell you anyway.

"Who's Marry? Your mother?"

No, she was my rabbit. Anyway, I can't do this:

let chestnuts = 50;
let chestnuts = 0;
console.log(chestnuts);

Output

SyntaxError: Identifier 'chestnuts' has already been declared

"Aha, so you can't steal them. Hey, look, another chestnut. Please store this one as well."

let chestnuts = 50;
chestnuts += 1;
console.log(chestnuts);

Output

Well, now that I look at them, I want them for myself. While I can't redeclare, I can reassign.

let chestnuts = 51;
chestnuts = 0;
console.log(chestnuts);

Output

"Noooooo, you give them back. I thought we were friends. Don't I remind you of your rabbit?"

We ate that rabbit. Bye now.

Const 🍄

So here you are again, all alone in the woods, your stomach growling, potatoless, chestnutless. You walk down to the creek and find a bunch of mushrooms. Quickly, you take as much as you can and think:

"Although I like stealing, I don't like it when someone does it to me. Is there anyone I can trust?"

You hear another voice, which makes you wonder where all of these voices are coming from?

Yo, what's good y'all! It's your boy const, the one and only true variable straight outta JS. I'm here to spit fire and drop some knowledge.

"Can you store this for me and not steal it?"

Ha, I guess you've met var and let. Not very nice, are they? But don't worry.

const mushrooms = 15;

"And what if someone tries to do this?"

{
  const mushrooms = 15;
}

console.log(mushrooms);

I got you, rabbit-man. Don't worry. Your mushrooms are safe.

Output

ReferenceError: mushrooms is not defined

"I have been cheated more than once. What about this?"

function protectMushrooms() {
  const mushrooms = 15;
}

console.log(mushrooms);

No way, I ain't like that. I am guarding your 'shrooms. We good.

Output

ReferenceError: mushrooms is not defined

"So you are also block scoped. Can you do this: "

const mushrooms = 2;

function protectMushrooms() {
  const mushrooms = 15;
}
console.log(mushrooms);

For sure. If you want them 'shrooms, tough luck.

Output

"And you can't steal them? What about reassigning and redeclaring?"

const mushrooms = 15;
const mushrooms = 0;
console.log(mushrooms);

const mushrooms = 15;
mushrooms = 0;
console.log(mushrooms);

Can't do that, ain't no way.

Output

SyntaxError: Identifier 'mushrooms' has already been declared
TypeError: Assignment to constant variable.

"Finally, I have found a friend. Oh look, another mushroom. Please store this one as well."

const mushrooms = 15;
mushrooms +=1
console.log(mushrooms);

I ain't with it, even for you, dawg, I'm out. I only keep values that don't change.

TypeError: Assignment to constant variable.

"What? I am deeply offended. Now I am starting to miss var and let."

You didn't just say that. Oh, I am hurt. I bet let and var didn't show you that we can do this:

const mushrooms = {
  amount: 15,
};
mushrooms.amount = 0
console.log(mushrooms);

Output

{ amount: 0 }

"Nooooooooo. Not again. I thought you can't reassign values!"

Well, I can't except when it's objects. I kind of dig their vibe.

Wrap-Up

After a whole day's work, you go home potatoless, chestnutless, mushroomless.

Out of all the voices you've met, var is the most relaxed one, it's function scoped. Storing values inside var is not very safe since those values can be reassigned and redeclared.
Let is a little bit more rigid since it doesn't allow redeclaring but it does allow reassignment. It's block scoped just like const which is the strictest of them all. It doesn't allow redeclaring or reassigning, but it does have a soft spot for objects.

Very useful knowledge for a medieval peasant, don't you think? 🐰

Trouble at the docks - part 1

Veronika Šimić — Tue, 24 Jan 2023 14:20:05 +0000

So you have written your code and you are feeling pretty proud about it and want to share it with your friends.

They pull the code from your github repo but something is not working right. Maybe it's because you have written all the code on Windows and your friends are using Linux. What should you do? Should you bring your computer to them and show them just how great your code is?

They live in Guadalajara and it would be nice to visit them but the plain ticket is pretty expensive and they are not that good of a friend.

One day you hear a rumor that there are some people by the docks who deal with these type of situations. These people are pretty dangerous, but you are brave aren't you? I mean, sometimes you go the the restaurant on your own. If that's not bravery than what is?

On a dark night you finally get up the courage to go to the docks. There don Porto awaits you.

Don Porto

Who's there? - a deep voice asks

Itttt-s me. I-iii came becuase I heard you can solve my problems.

Oh, yeah? What problems do you have? And how much money you got?

I need you to transfer some code for me. I have developed an
application but my friend can't run it on his computer.

Well, maybe you need a new friend. And what about my money??

I do not have any money. My mom told me that people are valued by what's inside their hearts not by what's inisde their wallet.

Your mom was messing with you. Ok since you do not have any money you will have to load the cargo by yourself. My crew will then ship it.

But I don't know how to operate the forklift. I have never worked on the docks.

Yes I can see that by your gentle hands. Don't worry you won't be needing any of that. Where is your code?

I have it on github. Let's clone it.

git clone https://github.com/veronika-simic/dev_docker_part1.git

Huh, and here I thought you are some kind of a genius. Let's start I haven't got all night.

What are you going to do? I don't wan't anyone to get hurt.

I am going to dockerize your code.

The secret

This secret has been passed down in my family for many generations. The secret called Docker.

What a weird family. Go on...

Well, Docker is a set of platform as a service products that use OS-level virtualization to deliver software in packages called containers. Containers have everything a software needs to run including libraries, system tools, code, and runtime. With it you can quickly deploy and scale applications into any environment and know your code will run. Basically what Docker does is it makes really easy to install and run software without you troubling your little head with setup or dependencies.

Well that sounds as exactly what I need. And my head is pretty small. Where are these containers?

Not very patient are you? Containers are not physical constructions. They are an instance of an image. We will start by creating a new file in your project called Dockerfile. Without any extensions. Everything starts with the Dockerfile.

Huh, not a very catchy name.

Nobody cares for your comments. Here put this code iniside the new file called Dockerfile.

FROM node:16-alpine

RUN npm install

CMD ["npm", "start"]

Ok what now? Is this a container? Can I go home now to my cat?

No. Fluffy will have to wait. This is just a baseline for our image which we are going to later send to your "friends". Then they can create a container out of it and run this very complicated code of yours.

What is an image? And what does all of this code do? And how do you know my cat's name?

Oh I have to explain everything to you... You are one of those people. When I say an image what I actually mean is a file system snapshot. An image is a physical file which contains directions and metadata to build a specific container. It has all the files and folders you have specified in your project. After you build the image you can redistribute it using the registry. The registry is like a Git repository you can push and pull images. Images can then be used to run containers. And you have your cats name tattooed on your forehead.

Wait, what?

Ok baby steps it is. Let's say you run Chrome on your computer. What happens is it calls the OS which then calls kernel and says: Hey I want to run this program. The kernel runs the files from your hard disk and you can now spy on your ex. Good for you. Imagine that Chrome uses Pyhton version 3 and Spotify uses Python version 2. What now? Does this mean that you can't at the same time spy on your ex and cry while you listen to "Everybody hurts"?

Have you been watching me?

Just a lucky guess. In order to make this possible, you need to use an operating system feature known as namespacing. A namespace is a feature which gives you the opportunity to isolate processes, hard drive, network, users, hostnames and so on. Now you can do both.

Aha so we are going to make use of namespacing?

Hey there might be some future for you. Yes, containers use namespaceing so we can provide isolation for running processes, limiting their access to system resources without the running process being aware of the limitations. It also means that docker images and containers are pretty small in size. So they are faster to run and install. Let's get back to our code. Build the image by running this command in terminal window:

docker build .

Hey but I get an error. What's going on? Are you trying to trick me?

The error you see is due to the fact that our temporary image built from node:16-alpine does not have it's own package.json. We have to copy it to the container.
We can do that by adding COPY . . statement to our Dockerfile.

FROM node:16-alpine

RUN npm install
COPY . .

CMD ["npm", "start"]

What are you doing? You can't run npm install before copying package.json. Put the COPY statement before the RUN.

Sorry, sorry. All this fish smell is making me dizzy.

FROM node:16-alpine

COPY . .
RUN npm install

CMD ["npm", "start"]

Great now everything is going to be copied from our project directory to containers directory. Now build the image again.

Ah, ok now it works. But what if my folder has the same name as the folder inside the container? I do not want to override it.

Aha. We can avoid this by specifiying the name of the folder we want in container. Then everything gets copied into that container. This container is by convenction called app.

Can we name it Fluffy though?

No.

FROM node:16-alpine

WORKDIR '/app'
COPY . .
RUN npm install

CMD ["npm", "start"]

So now everything is in this folder called app? How great! Let me build my image again. Can I name my image?

If you must. What would you like to name your image?

Masterpiece definitely. I mean have you seen what this code does?

Yes, I can't unsee it. Ok let's do that by running this command in terminal:

docker build -t masterpiece .

As you can see we have built your "masterpiece". The next step is to run the docker image. That way we create a container from our image. Remember container is a process that is running based on the files provided by the image.
Run this command in terminal:

docker run -p 3000:3000 masterpiece

Yes my container is running. Does the script start immediately because of the CMD ["npm", "start"]? And what is this weird command doing?

Well, what's happening currently when you run your app is that any call to localhost:3000 doesn't get redirected to your container. In order for us to achive that we had to use port mapping.
And yes, our script starts immediately because of the last command in our Dockerfile. There you can specify any command you want to use to start your script.

So what we are doing is saying to our server hey, any call that goes to localhost:3000 redirect it to my conatiner's port 3000? Can I specify any port number?

That's right. You can specify any port you want in the docker container. Just make sure that the port on your local machine is not already taken by some other application.

Ok what's next now that my container is running? How do I send it to my friend? And what about all the output in the console? What's going on there? And what if I decide to change something in my code? Do I have to rebuild my image again and again?

I see you are very interested in all of this. Unfortunately, I have to go take care of someone.

Aha ok. Then next time. Sorry did you say someone?

No, no. I meant something. Say hello to Fluffy. 🐱

The ultimate guide to async JavaScript

Veronika Šimić — Mon, 23 Jan 2023 11:25:44 +0000

On your path to becoming a JavaScript developer you will probably encounter callbacks, promises, and async/await.

JavaScript at its core is a synchronous or single-threaded language. What this means is that each action gets executed one by one and each action depends on the execution of the previous.

Think of it as cars waiting at the traffic light. Each car has to wait for the previous one to start. 🚗 🚕

const firstCar = 'first car';
const secondCar = 'second car';

console.log('Start ' + firstCar);
console.log('Start ' + secondCar);

Output

Start first car
Start second car

But what happens if the first car is broken? Should all the other cars wait? Who has time for that?

const firstCar = 'broken';
const secondCar = 'second car';

if (firstCar === "broken") {
  throw Error("The first car is broken. Everybody stop.");
}


console.log('Start ' + firstCar);
console.log('Start ' + secondCar);

Output

Error: The first car is broken. Everybody stop.

Well wouldn't it be better that each car does not depend on the previous one? Why should we care if some car is broken? If my car works why should I wait for someone to start their car? Can't I just go around it?

Well that's what asynchronous Javascript allows us to do. It creates another "lane" for us. Asynchronicity means that if JavaScript has to wait for an operation to complete, it will execute the rest of the code while waiting. We can move our actions out of the main lane and execute them at their own pace, let them do their own thing. And how do we acomplish that?

By using callbacks, promises and async/await.

Callbacks

Callbacks are functions which are nested inside another function as an argument. They can be used as part of synchronous or asynchronous code.

A synchronous callback is executed during the execution of the high-order function that uses the callback.

function startFirst(car, callback) {
  console.log("Start " + car);
  callback();
}

// callback function
function startSecond() {
  console.log("Start second car");
}

// passing function as an argument
startFirst("first car", startSecond);

Output

Start first car
Start second car

We can also make callbacks part of asynchronous Javascript.

An asynchronous callback is executed after the execution of the high-order function that uses the callback. If our car is broken then we will take it to mechanic and after that we can use it again. First we have to wait for some time to fix the car, which we will simulate by using setTimeout, and then we can enjoy driving our newly fixed car.

function fixMyCar(car) {
  setTimeout(() => {
    console.log(`Fixing your ${car}.`);
  }, 1000);
}

function driveMyCar(car) {
  console.log(`Driving my "new" ${car}.`);
}

let myCar = "Yellow Corgi CC85803"; // no wonder it's broken

fixMyCar(myCar);
driveMyCar(myCar);

Output

Driving my "new" Yellow Corgi CC85803.
Fixing your Yellow Corgi CC85803.

Javascript first executed the synchronous code (in our case call to the driveMyCar() function) and then after 1000 miliseconds it loged the result of the fixMyCarFunction().

But wait. How can we drive our car if it wasn't fixed yet?

We have to pass the driveMyCar() function as callback to the fixMyCar() function. That way driveMyCar() function isn't executed until the car is fixed.

function fixMyCar(car, callback) {
  setTimeout(() => {
    console.log(`Fixing your ${car}.`);
    callback(car);
  }, 1000);
}

function driveMyCar(car) {
  console.log(`Driving my "new" ${car}.`);
}

let myCar = "Yellow Corgi CC85803";

fixMyCar(myCar, driveMyCar);

Output

Fixing your Yellow Corgi CC85803.
Driving my "new" Yellow Corgi CC85803.

Well this is great we have fixed our car and now we can drive it.

But what if our car couldn't been fixed? I mean no suprise there, have you seen it? How are we going to handle errors? And what about fixing multiple cars every day?

Let's see it in action.

function fixMyCar(car, success, failure) {
  setTimeout(() => {
    car ? success(car) : failure(car);
  }, 1000);
}

const car1 = "Yellow Corgi CC85803";
const car2 = "Red Peel Trident";
const car3 = "Blue Yugo GV";

fixMyCar(
  car1,
  function (car1) {
    console.log(`Fixed your ${car1}.`);
    fixMyCar(
      car2,
      function (car2) {
        console.log(`Fixed your ${car2}.`);
        fixMyCar(
          car3,
          function (car3) {
            console.log(`Fixed your ${car3}.`);
          },
          function (car3) {
            console.log(`Your ${car3} car can not be fixed.`);
          }
        );
      },
      function (car2) {
        console.log(`Your ${car2} car can not be fixed.`);
      }
    );
  },
  function (car1) {
    console.log(`Your ${car1} car can not be fixed.`);
  }
);

Output

Fixed your Yellow Corgi CC85803.
Fixed your Red Peel Trident.
Fixed your Blue Yugo GV.

Is your head spinning trying to figure this out? Don't worry you aren't alone.
There's a reason why this is called callback hell or pyramid of doom. 🔥
Plus notice that if one of the cars is totaled, that is if it's unrecognizable (undefined), other cars won't even get the chance to be fixed. Now isn't that just sad? Don't we all deserve a second chance? 😊

function fixMyCar(car, success, failure) {
  setTimeout(() => {
    car ? success(car) : failure(car);
  }, 1000);
}

const car1 = "Yellow Corgi CC85803";
const car2 = undefined;
const car3 = "Blue Yugo GV";

fixMyCar(
  car1,
  function (car1) {
    console.log(`Fixing your ${car1}.`);
    fixMyCar(
      car2,
      function (car2) {
        console.log(`Fixing your ${car2}.`);
        fixMyCar(
          car3,
          function (car3) {
            console.log(`Fixing your ${car3}.`);
          },
          function (car3) {
            console.log(`Your ${car3} car can not be fixed.`);
          }
        );
      },
      function (car2) {
        console.log(`Your ${car2} car can not be fixed.`);
      }
    );
  },
  function (car1) {
    console.log(`Your ${car1} car can not be fixed.`);
  }
);

Output

Fixing your Yellow Corgi CC85803.
Your undefined car can not be fixed.

How can we avoid all of this? Promises to the rescue!

Promises

A Promise is an object that can be used to get the outcome of an asynchronous operation when that result isn't instantly available.

Since JavaScript code runs in a non-blocking manner, promises become essential when we have to wait for some asynchronous operation without holding back the execution of the rest of the code.

A JavaScript promise is an object that has one of the three states.

Pending - the promise still hasn't resolved (your car is at mechanic)
Fullfiled - the request was successful (car is fixed)
Rejected - the request failed (car can not be fixed)

To create a Promise in JavaScript use the new keyword and inside the constructor pass the executor function. This function is then responsible for resolving or rejecting the promise.

Let's imagine the following scenario. If our car will be fixed, then we can go on a holiday. There we can go sight seeing, then we can take some pictures, post them on social media because that's what cool kids do these days. But if our car can't be fixed then we will have to stay at our sad, little, dark apartment with our cat.

Let's write our steps.

Mechanic makes a promise, she will fix our car 🔧
Fixing the car means going to holiday. 🌴
Once there we can go sight seeing 🌄
We will take some pictures 📷
After that we will post them on social media 📱

(again we are using setTimeout to simulate asynchronicity)

const mechanicsPromise = new Promise((resolve, reject) => {
  setTimeout(() => {
    const fixed = true;
    if (fixed) resolve("Car is fixed.");
    else reject("Car can not be fixed.");
  }, 2000);
});

console.log(mechanicsPromise);

Output

Promise { <pending> }

And if you check the console you will get:

Promise { <pending> }

[[Prototype]]: Promise
[[PromiseState]]: "pending"
[[PromiseResult]]: undefined

But wait how is PromiseResult undefined? Hasn't your mechanic told you that she will try to fix your car? No, your mechanic did not trick you. What we forgot to do is consume our Promise. And how do we do that? By using .then() and .catch() methods.

const mechanicsPromise = new Promise((resolve, reject) => {
  setTimeout(() => {
    const fixed = true;
    if (fixed) resolve("Car is fixed.");
    else reject("Car can not be fixed. Go home to your cat.");
  }, 2000);
});

mechanicsPromise
  .then((message) => {
    console.log(`Success: ${message}`);
  })
  .catch((error) => {
    console.log(error);
  });

Output

Success: Car is fixed.

Let's check our Promise object in the console.

Output

[[Prototype]]: Promise
[[PromiseState]]: "fullfiled"
[[PromiseResult]]: Success: Car is fixed.

As you can see from the code block above we use .then() to get the result of the resolve() method and .catch() to get the result of the reject() method.

Our car is fixed and now we can go on our holiday and do everything we planed.

.then() method returns a new Promise with a value resolved to a value, we can call the .then() method on the returned Promise like this:

const mechanicsPromise = new Promise((resolve, reject) => {
  setTimeout(() => {
    const fixed = true;
    if (fixed) resolve("Car is fixed.");
    else reject("Car can not be fixed.");
  }, 2000);
});

mechanicsPromise
  .then((message) => {
    console.log(`Success: ${message}`);
    message = "Go sight seeing";
    return message;
  })
  .then((message) => {
    console.log(message);
    message = "Take some pictures";
    return message;
  })
  .then((message) => {
    console.log(message);
    message = "Posting pictures on social media";
    console.log(message);
  })
  .catch((error) => {
    console.log(error);
  })
  .finally(() => {
    console.log("Go home to your cat.");
  });

Output

Success: Car is fixed.
Go sight seeing.
Take some pictures.
Posting pictures on social media.
Go home to your cat.

As you can see after each call to the .then() method we chained another .then() with the message resolved to the previous .then().
We also added the .catch() to catch any errors we might have.
If we go or don't go to our holiday we will certanly have to go back home.
That's what .finally() does, this method is always executed whether the promise is fulfilled or rejected. In other words, the finally() method is executed when the promise is settled.

Our code looks a little bit nicer then when we were using callbacks. But we can make this even better with a special syntax called “async/await”. It allows us to work with promises in a more comfortable fashion.

Async/await

Async/await allows us to write promises but the code will look synchronous although it's actually asynchronous. Under the hood we are still using Promises. Async/await is syntactic sugar, which means althought it does not add any new functionality to our code, it's sweeter to use. 🍬

I don't know about you but I don't belive it until I see it.

const mechanicsPromise = new Promise((resolve, reject) => {
  setTimeout(() => {
    const fixed = true;
    if (fixed) resolve("Car is fixed.");
    else reject("Car can not be fixed.");
  }, 2000);
});

async function doMyThing() {
  let message = await mechanicsPromise;
  console.log(`Success: ${message}`);
  message = "Go sight seeing";
  console.log(message);
  message = "Take some pictures";
  console.log(message);
  message = "Posting pictures on social media";
  console.log(message);
  console.log("Go home to your cat.");
}

doMyThing()

Output

Success: Car is fixed.
Go sight seeing.
Take some pictures.
Posting pictures on social media.
Go home to your cat.

As you can see await keyword makes the function pause the execution and wait for a resolved promise before it continues. Await keyword can only be used inside an async function.

Hey but what if my car is broken? How do I handle errors with this new syntax?

Fear not. We can use try/catch block.

const mechanicsPromise = new Promise((resolve, reject) => {
  setTimeout(() => {
    const fixed = false;
    if (fixed) resolve("Car is fixed.");
    else reject("Car can not be fixed.");
  }, 2000);
});

async function doMyThing() {
  try {
    let message = await mechanicsPromise;
    console.log(`Success: ${message}`);
    message = "Go sight seeing";
    console.log(message);
    message = "Take some pictures";
    console.log(message);
    message = "Posting pictures on social media";
    console.log(message);
    console.log("Go home to your cat.");
  } catch (error) {
    console.log(error);
  }
}

doMyThing();

Output

Your car can not be fixed.

Only use try/catch block if an operation is awaited. Otherwise an exception isn't going to be catched.

So even if your car is broken and now you have to ride the bus at least you learned about asynchronous JavaScript. 😄