Is it a good practice using Observable with async/await?
I am using angular 2 common http that return an Observable, but I face with a problem that my code likes a mesh when I use nested Observable call:
this.serviceA.get().subscribe((res1: any) => {
this.serviceB.get(res1).subscribe((res2: any) => {
this.serviceC.get(res2).subscribe((res3: any) => {
})
})
})
Now I wanna use async/await to avoid that but async/await only work with Promise. I know that Observable can be converted to Promise but as I know, it is not a good practice. So what should I do here ?
BTW, it will be nice if anyone can give me an example code to solve this with async/await :D
Solution 1:
Chaining Observables in sequence, as you want to do in your code
Concerning your code example, if you want to chain Observables (trigger another after the previous emits), use flatMap (or switchMap) for this purpose :
this.serviceA.get()
.flatMap((res1: any) => this.serviceB.get())
.flatMap((res2: any) => this.serviceC.get())
.subscribe( (res3: any) => {
....
});
This one is better practice compared to nesting, as this will make things clearer and help you avoid callback hell, that Observable and Promises were supposed to help preventing in the first place.
Also, consider using switchMap instead of flatMap, basically it will allow to 'cancel' the other requests if the first one emits a new value. Nice to use if the first Observable that triggers the rest is some click event on a button, for instance.
If you don't need your various requests to wait in turn for each other, you can use forkJoin or zip to start them all at once, see @Dan Macak answer's for details and other insights.
Angular 'async' pipe and Observables work well together
Concerning Observables and Angular, you can perfectly use | async pipe in a Angular template instead of subscribing to the Observable in your component code, to get the value(s) emitted by this Observable
ES6 async / await and Promises instead of Observables ?
if you're not feeling using Observable directly, you can simply use .toPromise() on your Observable, and then some async/await instructions.
If your Observable is supposed to return only one result (as it is the case with basic API calls) , an Observable can be seen as quite equivalent to a Promise.
However, I'm not sure there is any need to do that, considering all the stuff that Observable already provide (to readers : enlightening counter-examples are welcome!) . I would be more in favor of using Observables whenever you can, as a training exercise.
Some interesting blog article on that (and there are plenty of others):
https://medium.com/@benlesh/rxjs-observable-interop-with-promises-and-async-await-bebb05306875
The toPromise function is actually a bit tricky, as it’s not really an “operator”, rather it’s an RxJS-specific means of subscribing to an Observable and wrap it in a promise. The promise will resolve to the last emitted value of the Observable once the Observable completes. That means that if the Observable emits the value “hi” then waits 10 seconds before it completes, the returned promise will wait 10 seconds before resolving “hi”. If the Observable never completes, then the Promise never resolves.
NOTE: using toPromise() is an antipattern except in cases where you’re dealing with an API that expects a Promise, such as async-await
(emphasis mine)
The example you requested
BTW, it will be nice if anyone can give me an example code to solve this with async/await :D
Example if you really want to do it (probably with some mistakes, can't check right now, please feel free to correct)
// Warning, probable anti-pattern below
async myFunction() {
const res1 = await this.serviceA.get().toPromise();
const res2 = await this.serviceB.get().toPromise();
const res3 = await this.serviceC.get().toPromise();
// other stuff with results
}
In the case you can start all requests simultaneously, await Promise.all() which should be more efficient, because none of the calls depends on the result of each other. (as would forkJoin do with Observables)
async myFunction() {
const promise1 = this.serviceA.get().toPromise();
const promise2 = this.serviceB.get().toPromise();
const promise3 = this.serviceC.get().toPromise();
let res = await Promise.all([promise1, promise2, promise3]);
// here you can retrieve promises results,
// in res[0], res[1], res[2] respectively.
}
Solution 2:
As @Pac0 already elaborated on the various solutions well, I will just add slightly different angle.
Mixing Promises and Observables
I personally prefer not mixing Promises and Observables - which is what you get while using async await with Observables, because even though they look similar, they are very different.
- Promises are always async, Observables not necessarily
- Promises represent just 1 value, Observables 0, 1 or many
- Promises have very limited use, you can't eg. cancel them (put aside ES next proposals), Observables are so much more powerful in their use (you can manage for example multiple WS connections with them, try that with Promises)
- Their APIs differ greatly
Use of Promises in Angular
Now even though it is sometimes valid to use both, especially with Angular I think one should consider going as far with RxJS as possible. The reasons being:
- Great portion of Angular API uses Observables (router, http ...), so one kind of goes with and not against the stream (no pun intended) by using RxJS, otherwise one would have to convert to Promises all the time while making up for the lost possibilities RxJS provides
- Angular has powerful
asyncpipe which allows for composing your whole application data flow of streams which you filter, combine and do whatever modification you want on it without interrupting the stream of data coming from server without a single need for thening or subscribing. This way, you don't need to unwrap the data or assign it to some auxiliary variables, the data just flows from services through Observables straight to the template, which is just beautiful.
There are some cases though where Promise still can shine. For example what I am missing in rxjs TypeScript types is concept of single. If you are creating an API to be used by others, returning Observable is not all that telling: Will you receive 1 value, many, or will it just complete? You have to write comment to explain it. On the other hand, Promise has much clearer contract in this case. It will always resolve with 1 value or reject with error (unless it hangs forever of course).
Generally, you definitely don't need to have only Promises or only Observables in your project. If you just want to express with a value that something was completed (deleting user, updating user), and you want to react on it without integrating it to some stream, Promise is the more natural way of doing so. Also, using async/await gives you the power to write code in sequential manner and therefore simplifying it greatly, so unless you need advanced management of incoming values, you can stay with Promise.
Back to your example
So my recomendation is to embrace both the power of RxJS and Angular. Coming back to your example, you can write the code as following (credits for the idea to @Vayrex):
this.result$ = Observable.forkJoin(
this.serviceA.get(),
this.serviceB.get(),
this.serviceC.get()
);
this.result$.subscribe(([resA, resB, resC]) => ...)
This piece of code will fire 3 requests and once all of those request Observables have completed, subscription callback to forkJoin will get you the results in an array, and as said, you can subscribe to it manually (as in the example) or do this declaratively using result$ and async pipe in the template.
Using Observable.zip would get you the same result here, the difference between forkJoin and zip is that the former emits only last values of inner Observables, the latter combines first values of the inner Observables, then second values etc.
Edit: Since you need the results of previous HTTP requests, use flatMap approach in @Pac0's answer.
Solution 3:
Observables are great for streams, eg: BehaviorSubject. But a single call for data (eg http.get()) you're probably better off making the service call itself async.
async getSomethingById(id: number): Promise<Something> {
return await this.http.get<Something>(`api/things/${id}`).toPromise();
}
Then, you can simply call it like so:
async someFunc(): Promise {
console.log(await getSomethingById(1));
}
RxJS is very powerful, but using it for a simple api call seems like extreme overkill. Even if you need to massage the retrieved data you can still make use of the RxJS operators inside the getSomethingById function and just return the final result.
The clear advantage to async/await is that it's clearer to read and you don't need to jump through hoops to chain calls.
Solution 4:
Since toPromise is deprecated now in 2022. I want to show another way of using await on an observable. I find this method to make much more readable code, as opposed to long, complex rxjs pipes. This is especially useful for http requests since there is only one response, and you generally want to wait for the response before doing something else.
Update
My initial solution works, but rxjs has basically the same function: firstValueFrom().
From the docs:
async function execute() {
const source$ = interval(2000);
const firstNumber = await firstValueFrom(source$);
console.log(`The first number is ${firstNumber}`);
}
If you have an observable, you can wrap it in a promise, subscribe, and resolve when the subscription completes.
getSomething(): Promise<any> {
return new Promise((resolve, reject) => {
this.http
.get('www.myApi.com')
.subscribe({
next: (data) => resolve(data),
error: (err) => reject(err),
});
});
}
Now we can wait for a response inside of an async function
async ngOnInit() {
const data = await this.getSomething();
//Do something with your data
}
Now we can perform plenty of complex operations on the data and it will be much more readable to people who aren't rxjs wizards. If you had three subsequent http requests that relied on each other it would look like:
async ngOnInit() {
const first = await this.getFirst();
const second = await this.getSecond(first);
const third = await this.getThird(second);
}