Angular Experiences: Promises Vs. Observables – Choose Your Destiny

Whether to use a Promise or an Observable is a valid question. Let me show you a little hint for deciding when to use what.

In this article:

Angular Experiences: Promises Vs. Observables – Choose Your Destiny
Thomas Hilzendegen is consultant at Thinktecture and focuses on large-scale Angular applications and their performance.

What are Promises?

Fun Fact: Promises are a commitment for value over time; they promise this.

But let me be more precise:

There was a time in JavaScript before Promises. It was a dark age. Every developer was scared to end in hell – the callback hell. A callback is a function called by a function to continue when something (maybe asynchronous) completes (please note, I am already using fat-arrow functions here, which is a much later introduced language feature):

				
					someMethod(input, output => {
  nextMethod(output, more => {
    hopefullyFinalMethod(more, realval => {
        dangThereIsMoreMethod(realval, () => alert('Now we are done!'));
    });
  });
});
				
			

This is just a small example – there are way deeper ones in the wild. Of course, you may define functions for all those callbacks and use them instead of the inline one. But things get complicated when the call context of the function needs to stay (e.g. this).

Rewriting the example above with Promises, presupposed the methods are capable of supporting this, we should get more arranged code:

				
					someMethod(input)
    .then(output => nextMethod(output))
    .then(mode => hopefullyFinalMethod(more))
    .then(realval => dangThereIsMoreMethod(realval))
    .then(() => alert('Now we are done!'));
				
			

You see, this is much more straightforward regarding the indentation. But still, you may notice the readability of the chained method calls is not yet the way it should be.

When async/await was available, you could start to write asynchronous code like it would be synchronous code by using the appropriate keywords:

				
					const output = await someMethod(input);
const more = await nextMethod(output);
const realval = await hopefullyFinalMethod(more);
await dangThereIsMoreMethod(realval);
alert('Now we are done!');
				
			

This code should be the final form – much more readable and easily understandable as you see the code flow immediately. Using Observables here would harm the readability instead if there isn’t a need for them at all.

Bonus: In case of async/await, the error handling is just a simple try/catch instead:

				
					try {
    const result = await asyncMethod();
} catch {
    alert('An error occured!');
}
				
			

What are Observables?

Speaking of Observables – what are they? In its simplest form, it can be like a Promise. It provides one value over time. But Observables are much more than this. An Observable is capable of delivering multiple values over time – it’s like streaming. It can be canceled or, in case of errors, easily retried. Numerous Observables can be combined, or there can be a race to have only the first used. The RxJS framework for Observables is a mighty one.

Furthermore, Observables need to have a subscription to start emitting values. Otherwise, they are just a blueprint of code handling future emits. If you create your own “producer” of values, you can react on subscribe and unsubscribe. You can then start, stop, or tear down the emit of values.

Creating your producer of an Observable is as simple as instantiating a new instance of it:

				
					const observable = new Observable(subscriber => {
    // ...
    // put your value-producing logic here
    // ...
    return () => {
        // ...
        // put your teardown logic here
        // ...
    };
});
				
			

The given “subscriber” instance has the method next(value) to provide values. In case of an error, the method error(error) should be called. And, when there are no more values, the method complete() should be finally used.

Where Promises May be the Better Choice

One rule-of-thumb could be that everywhere you want only one value over time, e.g., from an HTTP request, you should use a Promise. Usually, this shouldn’t be a problem if you accept the following drawbacks:

Drawbacks

  • You cannot easily cancel a Promise.
  • You cannot easily repeat or retry a Promise.

Why could these drawbacks be a problem for you? Let’s assume that you are developing an Angular application. You usually request some data when the user navigates to your component. When this takes a while, and the user navigates away, the HTTP request continues and completes by downloading all the “useless” data. Of course, this could somehow be archived by implementing some complex logic or use an already built framework for this.

On the other side, to repeat or retry a Promise, you also need some even more complex logic to achieve it (or use a library, if available).

Where Observables may be the Better Choice

The first argument for using Observables is handling streaming data – multiple values over time. Without them, you would need to have a callback registering logic to inform others about new values. But this may be just the simple form of it. Starting with more complex scenarios where, e.g., retrying, repeating, or canceling is a topic, you may get lost in writing so much code instead of using an operator function.

For deeper information about Observables, you may have a look at my colleague Yannick Baron’s three-part webinar series (in German), starting with part one RxJS von Grund auf: Einführung in reaktives JavaScript.

But sometimes, even when only one value is available, building an Observable pipe could be the better choice if the code would be much more complex without it.

Drawbacks

  • You have to learn a complex framework.
  • You could tend to use Observables everywhere.

As mentioned earlier, the RxJS framework is a complex one. There are so many operators and possibilities to work with that reactive programming style.

Conclusion

With great power, there must also come great responsibility. It would be best not to use Observables as an answer for any problem coming up. Code can look way more difficult to understand when Observable pipes get significant, or the reactive way is unnecessary at this particular point in the code.

Free
Newsletter

Current articles, screencasts and interviews by our experts

Don’t miss any content on Angular, .NET Core, Blazor, Azure, and Kubernetes and sign up for our free monthly dev newsletter.

Related Articles
.NET
Incremental Roslyn Source Generators: Using Additional Files – Part 7
In the previous article the Source Generator itself needed a 3rd-party library Newtonsoft.Json in order to generate new source code. The JSON-strings were hard-coded inside the Source Generator for simplicity reasons. In this article we will see how to process not just .NET code, but also other files, like JSON or XML.
21.03.2023
Entity Framework
Entity Framework Core 7 Performance: Cartesian Explosion
In Entity Framework Core 3 (EF 3) the SQL statement generation (re)introduced the Cartesian Explosion problem. A lot has happened since then, so it is time to revisit the issue with Entity Framework Core 7 (EF 7).
14.03.2023
.NET
Understanding and Controlling the Blazor WebAssembly Startup Process
There are a lot of things going on in the background, when a Blazor WebAssembly application is being started. In some cases you might want to take a bit more control over that process. One example might be the wish to display a loading screen for applications that take some time for initial preparation, or when users are on a slow internet connection. However, in order to control something, we need to understand what is happening first. This article takes you down the rabbit hole of how a Blazor WASM application starts up.
07.03.2023