💥 Angular Mistake #4: 🛑 STOP Avoiding Using Promises #angular

Timestamps:

0:00 Intro
01:58 Angular Mistake #4
04:42 Promise Support in Router Resolvers
07:15 Refactoring a component into async / await code
12:20 The bottom line

Free content at the Angular University:

Follow me:

[moitp]

I commented on your previous video about the same subject. I'll do it again :D

First of all, the claim that the Angular team would like to slowly make RxJs "optional" is somewhat arguable. Why? Because in their roadmap, they specifically state that they would like to upgrade to RxJs 8. This would make no sense if they intend to eliminate it. Additionally, they are promoting Signals instead of BehaviorSubject services, which is not the same as eliminating RxJs for asynchronous operations. So yeah, we are gradually going to stop using RxJs for synchronous tasks, but it will still be the main recommendation for asynchronous operations.

Now, let's talk about your first example. Like in the previous video, it's not a one-to-one comparison. The forkJoin is performing two requests in parallel, whereas calling two await methods will execute those requests sequentially. A more valid comparison would be to use Promise.all(). So, how is this less complex than the forkJoin operator? And I apologize, but you don't have to spend hours learning RxJs to know the forkJoin operator; it's one of the most common ones.

Regarding your second example, once again, you are using combineLatest when you should use forkJoin. combineLatest has no advantages over forkJoin if the two observables are HTTP calls. Moreover, you don't have to unsubscribe from a forkJoin observable, whereas you do for a combineLatest one. A scenario where combineLatest becomes useful is when you have, for example, a Subject/BehaviorSubject containing some state that can change. Each change triggers a new HTTP call thanks to the combineLatest operator. And it that case, it's even simpler to use RxJs than Promises.

If you can eliminate the combineLatest operator, then you don't have to use the startWith operator either, which brings us back to the first example. As I already mentioned, the first example using RxJs accomplishes more than the Promise equivalent.

I've mentioned this in your previous video, but with Observables, you get much more than promises out of the box. Observables are easily cancellable, retryable, and cacheable, for example.

As much as I enjoy your content, I just can't agree with these arguments about RxJs vs. Promises :) Keep up the good work, though!

[jtpoltorak]

Vasco, you are the man... great video, I learned a lot. Keep these videos coming!

[nunoarruda]

Promises or Observables are both fine and valid options. Just make sure you use the right one depending on the use case. For example, Observables are cancelable, Promises are not.

[gabrieldelosrios]

RXjs team here, let's be honest it's not about better code, it's about a broader audience, the angular team is pushing for angular to be more beginners friendly, but it doesn't mean that it being easier to grab also means better coding, in fact i think this could actually take us in the opposite direction, great video anyway.

[burningtree]

Right on brother, well said. Let’s get back to simple 👍

[MagicPepe]

forkjoin is better, because you dont wait first query to end like in async await example

[BrendanAlexander]

I love this channel. Thanks for the great tips!

[codeSurvivor]

Beginners, be aware that what seems simple today because of being imperative will become messy once you need to add changes or the complexity increases. If I knew this when I started i would invest my time in learning what declarative and reactive programming are and how to apply these patterns once being familiar with Angular. It would have saved me and the frontend team I work with a lot of struggle. Simple is not necessarily easier to maintain, well programmed and extensible code is definitely easier to maintain, and that, for sure, is not imperative programming

[megarustog]

Very helpful again. I find writing components like this to be significantly more understandable than the declarative and more reactive approach encouraged by default. I'm currently wrapping my head around understanding when to use both and what the best default approach is. It doesn't seem like there is an easy answer to such a question and it very much depends on circumstance.

[haroldpepete]

some people think angular is not using javascript behind the scene, when they look observable, subject, rxjs operator they think, wait a minute that's not javascript, that's something else

[undefined-nv]

But I don't like promises anymore 😁

[Maxim.Shiryaev]

IMHO, like in non-async code we use scalar variables for a single value and array/collection and for-loop, for async code we should use Promise for a single future value and Observable for a series of values. http in Angular was wrong in that sense from the beginning since request returns just one result.

[zirexpl]

I am working almost 3 years with angular/net. When i see now ur approach with promises, I start to wonder why the heck we are using rxjs :D (i hate it! And promises seems to look almost like c# code :D) Does it have any benefits? What about performance? Does promises have any disadventages?

[gabrielordonez]

Hello, excellent explanation as always, I would like to obtain the code used in this video to understand it better.

[stephendebeauchamp]

nope, jumping from one foot to the other isn't something most companies I've worked for are okay with, the project uses RxJS so we'll stick to it as it's a clear path from there to signals and working with streams makes more sense for the patters we use, I appreciate the post, but I'm not going back to explaining async/await

[PackAndGoFamily]

Hi, would you know if I have a component A which extends a directive B.
And in comp. a I am in injecting a service A with inject and inside of the constructor I am also calling super and injecting the service A. The question is, am I creating 2 instances os service A? Thanks in advance.
Example:

Class component A extends Directive B….
Service = inject(serviceA)
Constructor() { super(inject(serviceA) }

In that case am I getting same instance right?

[jimmyelkada]

The promises code is longer and less readable and maintainable ....

[seanszarkowicz]

Do you think HTTP calls will be Promised based in the future of Angular? Its makes doing sequential / dependent API calls easier at the start of using Angular? RxJS for more advanced feature if needed for HTTP

[mauroavon]

but those who use ngrx will have to continue to use rxjs and observables a lot for effects and selectors I imagine.. or can they use promises?

[phuoctoanchauhuynh]

Can I ask you what server rendering side concept is is in Angular 17, why it has been provided, and what is it used for? I completed the update of your Angular Core Deep Dive with version 17, but I don't see the part that notices that. Thank you for sharing.