Thought Leadership
Aug 10, 2022

The observables, I promise to callback later.

Get to know observables and say “hasta la vista” to promises.

The observables, I promise to callback later.

Having a hard time understanding Observables? Fancy words aside, let me give a real world example that’ll put you on track to master observables.

⚠️ This is going to be an, almost, code-less post.

Ok, so you’re into web development, hence, I’m pretty sure you have already heard and probably used callbacks and promises. As for observables, if you’re into Angular you’ve at least heard about them. Fear not, I’m going to give you a quick introduction of them and a real world example of each. Buckle up and let’s go!

Callbacks

This was the way to chain methods and functions back in the ol’ days, you have one function that receives n parameters plus one that would be another function to be called at the end of the called function. Simple, call another function at the end of the scope of the first function.

The issue with this is something called...

Callback hell!

A dark place, void of hope, filled with the souls of junior developers that got lost in the amount of indentation that their IDE requires to show all those callbacks.

Promises

From MDN Web Docs:

The Promise object represents the eventual completion (then) or failure (catch) of an asynchronous operation and its resulting value.

In short, a promise is an object that runs asynchronous code that can complete or fail.

Even though promises are a better way to handle running code sequentially for asynchronous code, you can still find bad patterns, for example having a lot of then and catch inside other then, oh no! Promise hell here 😨

Observables

Observables and promises have multiple differences between them, but one of the most important is the ability for observables to handle not one but multiple values.

It means that the same observable can be run multiple times, instead of just once, and can handle or respond to different events.

Another difference is that observables are not immediately called, like promises; they’re called once you subscribe to them.

Beware, even with observables you can incur bad practices, for example subscribing to another observable inside the function of subscription to another observable… much like adding then and catch inside other then.

So… where are the real life examples?

Ok, without going into code, I’m going to try to explain the main differences using real life scenarios. You’ll notice that callbacks and promises will look similar if not the same, but when I get to observables, you’ll notice the difference.

When I was a kid, my mom used to take me to the supermarket, when it was time to pay and we were in the checkout line, my mom would remember something that she missed and told me to go.

She would say, go and look for this brand of milk and if you find it, then bring 2 bottles, and if by chance you can still carry something else, bring a bar of butter. That would be callbacks, you run a function (searchBrand) and then you run another function (takeBottlesOfMilk).

Other days she would send me to the store across the street to get just one item (e.g. a bottle of Coke) and gave me her credit card and some money: “try to pay this with my card, but if they are having troubles accepting card, then pay with cash. I bet you’re seeing the promise in this, try to pay (payItems) which can resolve (then) or reject (catch) with different things to do in both cases. Oh! And finally I went back home, no matter the outcome of the promise.

💡 You can see from the examples above that the callbacks and promises scenarios look and could be handled pretty similar, but the observables one is a different approach, and the main difference is that we’re being reactive instead of imperative.

Give me my observables example!

Hold on your horses! I was setting the ground before we get to the observables.

With observables, things are a bit different, instead of me being the protagonist of the scenario, think about the cashier. They are the observable, which has a given set of instructions to handle customers, e.g. how to greet the customer (greetCustomer()), how to correctly handle all their items (handleItems()), how to ask for the payment (askForPaymentMethod()), do the payment (chargeAmmount()) and then give the client the receipt (handleReceipt()); but they don’t do anything until the client arrives; and she will follow the same set of instructions for each client.

When the cashier timestamps their card, they start working, hence subscribing to the job day, it doesn’t matter that the cashier already knows what to do, or that the store is already open with customers (app is running) in different aisles (components or pages), it’s until the cashier starts working (subscribes) that they will wait for customers (values) to arrive.

And after a long day of work, nothing better than unsubscribing from work and going to rest (free up used memory)… If they work extra hours I’m pretty sure a memory leak could happen in their brain! 🤯. And we know bad things happen if a memory leak happens

Final thoughts

I hope that my real world scenarios helped you get a grasp at the differences of callbacks, promises and, most importantly, observables. Using observables also requires a change in the paradigm that you use to code, from imperative to reactive; which I’ll talk more about the difference between both in my next post.

. . .
Article Summary
Struggling with observables in Angular? Learn how they work with real-life examples that make callbacks, promises, and observables easy to understand—no code needed!
Author
Eduardo Roth
Software Engineer
Related Articles
Open Source Insights Delivered Monthly

By clicking “submit” I acknowledge receipt of our Privacy Policy.

Thanks for signing up for our Newsletter! We look forward to connecting with you.
Oops! Something went wrong while submitting the form.