In Angular, you can perform asynchronous actions in two different ways, Observables, and Promises.
Most people pick Observables because every exam...
For further actions, you may consider blocking this person and/or reporting abuse
I really liked the format and art of the article!
I tend to use observables as they are more powerfull than promises, with al the rxjs utilities. But I use them mostly for HTTP requests and such. Though I agree there are some cases as you point out, where promises should be prefered.
Yeah, Observables are very powerful! They offer a great variety of tools to build reactive interfaces. But we should pick the best tool for the job, right 😉
That's it, picking the right tool for the job. you wouldn't use a toothbrush to clean the house right? :P
🤣🤣🤣🤣 would be a great accomplishment! But yeah true!
According to this post, because Observables are faster.
When I read the post, I can't find actual evidence in what way Observables are faster.
A person on StackOverflow has run a great test to measure the performance of a Promise and Observable. There you can see that a Promise is more performant than an Observable.
But that's not the only point of the Promise vs. Observable debate. Just pick the right tool for the job.
I found this great list on StackOverflow on when to use one over the other; maybe it's helpful to you.
Use Promise instead of an Observable, when:
Use Observable instead of a Promise, when:
Source: StackOverflow
Everything seems to be in Observables in Angular, so after a little experience, you get good at going between the two for your needs. I think it helps you master async techniques in general. I tend to use
.pipe(take(1)).toPromise();all the time, but never go from Promise to Observable. As you said, they have different uses, depending on the data source.The test right under that, which to me reads as a better test anyway: Observable wins.
Interesting article, thanks! A doubt: for http requests do you use HttpClient and return a toPromise() of that? (...so your article pops out others questions... as far i can see it's an old and resolved debate about HttpClient :)
Yes, most of the time I use
toPromise()😉Observables are great until you need to make a series of simple API calls in succession. You can use setTimeOut and guess how long each call will take but that’s pretty janky imo, or you could chain subscriptions, although isn’t that the “callback hell” we were trying to avoid with Promises? Or you can still use a series of Promises await them to ensure the succession and then combine them into an observable response? Finally, you can of course just do a straight up promise when you need a pull of non transforming data from the server or a straight up Observable when you have a value that does change over time and is using the server push paradigm. Push vs Pull is definitely the key to understanding when to use each effectively. Thanks for the article, I enjoyed it and totally agree!
I totally agree.
Code, like everything else, should be simple and direct.
In almost 100% of the daily tasks one can use a simple Promise instead of over-engineering with Observables.
Most views are basically (click/event => get results using criteria => show results).
Promises tend to make your code end up looking very similar to the logic, especially with using await/async (click => wait for result => show result), and Observables tend to create indirect implmentations (when the text changes put it somewhere, something else will make sure the results are updated later). For me, indirect implementations are very very bad.
Observables are very powerful for infrastructure-like stuff (like Base classes, global services, etc...) and they should be prefered there.
It's simply another case of the right tool for the job.
While I completely agree with you when you say it's not necessary for everything, I highly recommend developers in my team to prefer Observables over Promises when working with Angular. The top reasons are consistency and flexibility.
Anything you do with a Promise can be done with an Observable, but that's not true the other way around.
Also, you don't need to unsubscribe from Observables which use the HttpClient, which seems to be the only example of extensive use of Promises you've given, but that doesn't free you up from unsubscribing in other situations. That is, nothing has changed.
In the end, I'll stick to Obsevables in my HTTP calls because pipe, map, and other RxJs operators just make my life a lot easier when it comes to preprocessing responses, and is specially helpful when the requests have asynchronous parameters, which is not uncommon.
And last but not least, I'd rather have a new junior developer learn RxJs well to deal with our Angular code base, than having them learn both, if they have that technical debt. They can learn Promises later and that will not be an impediment to deal with our code base.
The only time I make use of Promises is when I don't already have RxJs as an inevitable dependency. For example when I'm writing a simple script or smaller project, and I see it would be overkill to use RxJs. If there are not restrictions I'll use Promises, which are way more elegant than callbacks, but I'll use callbacks if there's a good reason to.
I think not using RxJs for everything in Angular would be similar to writing Assembly code to optimize a part of and application you're writing in C, because of resources or speed. At this point you have to ask yourself: Is that really making much of a difference?
Everyone is entitled to their preferences though.
Well, technically Observable from http request is finite if I recall correctly, so in most cases you can disregard unsubscribe. But yeah, no need to be fixed on Observables alone 🤓
True, that's the beauty of an Observable. You can unsubscribe to it! 👍