DEV Community: Marina Costa

Illustrated JS: Promises

Marina Costa — Tue, 11 Aug 2020 19:46:42 +0000

While learning JavaScript and programming in general, I find it useful to create some analogies to understand the concepts better. Here I will share an analogy about Promises in JavaScript. Feel free to contribute in the comments.

In Javascript, if we want to call a function only after an asynchronous function returns, we can use callbacks. Let's say I'm baking a cake with chocolate icing, in that case, my bakeCake() function is asynchronous and takes prepareIcing() (that's the callback) as an argument, calling it only when the cake is completely baked.

Fig.1 - The baker responsible for the baking cake action is calling back the function responsible for the icing preparation after the baking is finished

But in this article we're focusing on using Promises. So how promises can help solve this problem? A promise is an object that wraps an asynchronous action and can be fulfilled with a value if the operation is successful or rejected with a reason, if it fails. This way I'm able to add a handler for a value (or a reason) that I will have only at some point in the future.

Fig.2 - My baker likes to use cakes to explain stuff

Going back to the baking example, I can say my oven is a promise of a cake, because it wraps my baking cake action and starts with a pending state (it's still baking). But I have a smart oven that will tell me when the action finishes. If the baking was successful, it's fulfilled with a cake. Otherwise, it's rejected with a burned cake or any other reason for the failure.

Fig.3 - The oven is a promise of a cake that starts with a pending state and let's me know when it's fulfilled (success cake) or rejected (failure cake)

Like we said before, using promises, we can add handlers for its possible states when it settles (it is either fulfilled or rejected). The .then() method can handle both success and failure (less common), and the .catch() method only can handle failure.

This is how I would handle a baking simple cake (no icing) action: if it is successful, then I can serve the cake. But if I burn my cake, I can catch the failed cake, throw it in the garbage and order a pie for my dessert instead. 😂

Fig.4 - If cakeBake() is fulfilled, then call the success handler, the serveCake() function. Otherwise, we catch the reason (burned cake) for the rejection and call the failure handler, the orderPie() function

Another thing to keep in mind is that, since one promise returns another promise, they can be chained. In my previous cake with icing example, I can finish baking my cake, then prepare the icing, then with both the cake and the icing ready, cover the cake. In that case, if any of the promises in the chain fails, I can handle all the rejections with only one catch and order a pie.

Fig.5 - Promises chained with .then() and catch() to handle successes and failures

But there's a better way to do what we did in the last example. My bakeCake() and my prepareIcing() functions are independent, which means they can happen at the same time. For that, we can use Promise.all() to wait for both results (cake and icing) before executing the coverCake() function.

Fig.6 - Promise.all() handles both the promise of the cake and the promise of the icing before covering the cake

Inside Promise.all(), if any of the promises rejects (fails), the entire promise is rejected. Which makes sense, right? I can't cover the cake if either the cake or the icing is missing.

This was a very simplified and summarised explanation of the concept of Promise, and the use of .then(), .catch() and Promise.all() methods. I hope it was clear enough.

Thanks for reading, feel free to contribute in the comments. I promise my next article is already in the oven right now (pending). And eventually, I'll share it on my twitter as soon as it's fulfilled or I'll post pictures of cats if it's rejected.

Bullet points for this article:

Promises are objects wrapping asynchronous actions.
Promises start with a pending state, and at some point in the future they settle to a fulfilled (success) or rejected (failure) state.
A promise returns a new promise that can be used for chaining.
We can add handlers to the success value or the failure reason once the action returns, by using .then() or .catch().
Promise.all() waits for all the promises to be resolved. If any rejects, it's rejected.

References and recommended further reading

Illustrated JS: JavaScript asynchronous behaviour
Asynchronous programing in Eloquent JavaScript by Marijn Haverbeke
Using promises in MDN Web Docs

Illustrated JS: JavaScript asynchronous behaviour

Marina Costa — Thu, 06 Aug 2020 10:51:00 +0000

While learning JavaScript and programming in general, I find it useful to take notes and create some analogies to understand the concepts. Here I will share some of my notes about the asynchronous behaviour of JavaScript and the fact it’s single threaded. Feel free to correct me if I understood something wrong.

JavaScript has only one thread running for each process. I think about it as a kitchen where only one baker is in charge for the process of baking a cake with chocolate icing.

The baker is the CPU and they would have to execute one subprocess at a time: baking the cake and preparing the icing. After that, the same person would also have to cover the cake with the icing.

Fig.1 - One baker (CPU) doing one subprocess at a time (single thread)

If it was multithreaded we could have only one CPU executing different subprocesses at the same time (baker with more arms).

Fig.2 - One baker (CPU) doing multiple subprocesses at the same time (multithreads)

Or we could have more CPUs (bakers) working in different subprocesses: cake preparation, icing preparation and cake covering.

Fig.3 - Three bakers executing subprocess concurrently

But in that case, the third subprocess (covering the cake) would need resources from the other two. So it would be necessary to add synchronisation to those actions, but let’s not focus on that right now.

Although multithreading maximises the CPU time, it’s a little bit more complex because it's harder to handle the concurrency, and the results are unpredictable.

Fig.4 - Unpredictable results in multithreading (absolutely exaggerated)

It's also important to mention that JavaScript is single threaded but it’s not synchronous. It means it doesn't need to completely finish one task before starting another one.

If that was the case, my baker would have to keep waiting for the oven to finish baking the cake, for instance, before being able to start the icing preparation.

Fig.5 - The baker is waiting for a slow action (baking the cake) to return before starting the icing preparation

In fact, JavaScript has some resources that allows us to make it asynchronous, and in our cake example, the baker is able to start making the icing while they wait for the cake to be baked.

Fig.6 - Starting the icing preparation without waiting for the cake preparation action to be finished

But let’s say our baker finishes the icing and the cake isn’t baked yet. Without the cake, they would not be able to move to the next step, which is covering the cake with the icing.

Fig.7 - The icing is finished before the cake, but the baker can't do the next task (covering the cake)

Many operations in JavaScript depend on external responses like interactions with APIs or network communications and we don’t know for sure when we are going to receive the result of those actions.

That's why we need to make sure that those dependent actions won’t be executed until we have access to the responses they need. For that, we can use promises and I'll talk about that on my next article.

Fig.8 - A promise object wrapping an asynchronous action (baking the cake)

How to get started with testing in React?

Marina Costa — Wed, 29 Jul 2020 08:11:08 +0000

Hello there, right now I'm focusing on learning testing in React, but I've been facing a hard time trying to find good material about that. Some tutorials that I find are too shallow or a little bit outdated and maybe I'm still too newbie to understand the documentation.

What do you think? How did you get started with testing in React? Which resources do you recommend? (Bonus point if it's free or cheap)