💥 Angular Mistake #4: 🛑 STOP Avoiding Using Promises

Angular Mistakes Series Playlist - • 💥Angular Mistakes #1: ...
- Angular Mistake #1 - Don't Overuse the Angular Async Pipe - • 💥Angular Mistakes #1: ...
- Angular Mistake #2 - Stop Using RxJs For Doing Simple HTTP - • 💥 Angular Mistakes #2:...
- Angular Mistake #3: Stop Fixing RxJs Memory Leaks This Way - • 💥 Angular Mistakes #3:...
- Angular Mistake #4: STOP Avoiding Using Promises - • 💥 Angular Mistakes #3:...
- Angular Mistake #5: STOP Overusing OnPush Change Detection - • 💥 Angular Mistake #5: ...
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:
- 20% of our lessons are free, you don't have to login to watch the lessons. The free lessons are the ones with the P (Pro) - angular-university.io
- Watch the free Angular For Beginners Course - angular-university.io/course/...
Follow me:
Twitter - / angularuniv
Facebook - / angular.university
KZbin - / @angularuniversity
Instagram - / angular.university
LinkedIn - / angular-university
TikTok - / angularuniversity
Threads - www.threads.net/@angular.univ...

[@AngularUniversity]

Check out here the playlist for the full Angular Mistakes Series kzbin.info/www/bejne/aaDUXpqked-tb80 😊 If you are looking to learn Angular, check out my courses for all levels, Beginner to Advanced at the Angular University - angular-university.io

[@moitp2]

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!

[@AngularUniversity]

For what we know, RxJs will not be eliminated, but it will become optional. It's the Angular team on interviews that mentions this, and I think that it makes a lot of sense. It's true that RxJs is used in a lot of places where it probably shouldn't. My main point with the videos is that it's way easier to write HTTP code using async/await. Those properties that you mention are rarely needed. When was the last time that you actually needed cancellation and retries in a project? it's like using a canon to kill a mosquito. 😊 You can easily get those properties if you really need them via libraries. Noone uses RxJS outside Angular and they do just fine, that's my main point. 👍 Consider a simpler way of doing things. 😉 Thank you for commenting.

[@PlerbyMcFlerb]

I suppose you don't need to unsubscribe from a combineLatest either as long as every observable inside it is finite, no? For this reason I never use forkjoin, and just stick with combinelatest.

[@moitp2]

@AngularUniversity, I apologize, but perhaps you don't need cancellation and retries in your project. Still, I can tell you that I do. Additionally, you didn't mention caching-why is that? :) "You can easily obtain those properties if you genuinely need them through libraries." How is this better than using an official tool supported for years by the Angular team? What draws people to choose Angular over other solutions is the assurance that they won't waste time searching for the best library to perform a specific task. Regarding other frameworks, you may be overlooking Svelte. Solid.js also employs its version of Observables. While neither is React nor Vue, Svelte remains a popular framework. Moreover, just because others aren't using a specific tool doesn't mean they have an easier life. Compare their approach to handling HTTP calls with our use of Observables; in many cases, it doesn't seem more efficient. Every time a task is slightly more complex than a single HTTP call, the situation worsens. Your example demonstrates this, even though there's a mistake since they don't perform the same function. A forkJoin equivalent would be Promise.all(), which doesn't simplify the code. You end up with the same number of lines and use some form of operator. Moreover, you'll need to employ a try/catch, whereas an operator suffices, requiring fewer lines of code. Also, as I mentioned in the other video, what about ngOnInit? It is no longer necessary with observables. As I said in the previous video : let's agree to disagree on that subject :)

[@mr.nefario]

Have nothing to add. Just perfect

[@jtpoltorak]

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

[@AngularUniversity]

Thanks! Will do!😊

[@AleksandarT10]

Great one. Keep the series coming!

[@AngularUniversity]

Thank you. 😊

[@brendanalexander6053]

I love this channel. Thanks for the great tips!

[@AngularUniversity]

Thanks for watching! 😊

[@burningtree878]

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

[@AngularUniversity]

Thank you 😊 Yes, let's do it. 😉

[@gabrieldelosrios811]

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.

[@AngularUniversity]

Thank you, I've made a summary about RxJs becoming optional here kzbin.info/www/bejne/q4CslXyCr5J3odk, where I quote the original sources from the Angular team (links in the description). I think not having RxJS in the main learning path of the framework will be very helpful for the whole ecosystem. There will be interoperability for those that choose to use it.

[@ratg97]

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

[@AngularUniversity]

You can do parallel queries in promises too with await Promise.all(...)

[@ratg97]

@@AngularUniversity thx for answer

[@zSandman99]

@@AngularUniversity It would have been helpful to include this tin the video. Thank you for these videos I've been learning a lot.

[@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.

[@AngularUniversity]

Thank you it's awesome to hear that. I think for typical HTTP code promises are a great default, I would use RxJs only when and if needed. It's all about using the right tool for the job. 😊👍

[@tarquin161234]

I would recommend learning to write declarative rxjs focused code. I work on an extremely complex front end project and it would be hell with an imperative style. I would never go back to imperative. People recommend it for a reason.

[@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.

[@AngularUniversity]

Sure but when was the last time you actually needed cancellation? You can cancel HTTP with promises as well, it's no problem. There are simpler solutions for the problem that don't involve such a complex library like RxJs, that's my main point.

[@nunoarruda]

2 use cases immediately come to my mind: type-ahead search with DB requests and navigating away from a route in the middle of an HTTP request.

[@PlerbyMcFlerb]

​​@@AngularUniversityfor me the answer is today 😂. I do it ALL THE TIME for quick finds etc or just preventing network chatter from a click-happy user. I've seen people oversell the cancellability, but I think you are underselling it

[@Schwartz_ls]

If your call to the DB requires cancellation. Then use RXJS. It’s not going anywhere and for a good reason. However, not all calls need to be cancellable. I believe this is what he is arguing. Not my style, but I can see the mans point as well as see yours.

[@gabrielordonez7876]

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

[@AngularUniversity]

Thank you Gabriel 😊 The code I didn't keep around, it was just a quick example I came up with on the fly 👍

[@mauroavon7239]

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?

[@AngularUniversity]

You can use NgRx Signal Store, that uses async await but it has interoperabiblity with RxJs. I just finished recording a video for it on the channel, going live tomorrow 😉

[@leiayuri]

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?

[@AngularUniversity]

What gets injected depends on what you set up as the injection token. Stay away from inheritance in Angular, don't ue extends at all it's an anti-patttern. Directives are meant mostly for composition, not inheritance. That ay of programming in Angular is highly discouraged.

[@leiayuri]

@@AngularUniversity thank so much for your advise. I will try to convert and use the composition way. BTW do u have any video talking about that?

[@AngularUniversity]

@@leiayuri you're welcome currently there is no video, but it's general practice in the Angular ecosystem to avoid inheritance. 👍

[@zirexpl6395]

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?

[@AngularUniversity]

There aren"t any disadvantages. RxJs handles very well certain rarely needed edge cases, but you can handle those with libraries. No need to write your whole application in RxJs just in case you need it. 😉 My team has been using minimal RxJs for well over a year, and things work way better this way.

[@phuoctoanchauhuynh8557]

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.

[@AngularUniversity]

SSR allows to create the initial HTML payload on the server. Then the client application takes over in the client as normal. 👍

[@phuoctoanchauhuynh8557]

@@AngularUniversity Thanks for your response. I just wonder if we make the markup render on the server side it will take many resources of the server, maybe it will slow down the response and consume more bandwidth than the normal approach. If this is true, what benefit will we gain from the trade-off?

[@AngularUniversity]

@@phuoctoanchauhuynh8557 In principle the startup time is slightly faster, and the user sees content on the screen way faster. So from the point of view of the user it's better. You do need a Node server with some normal CPU and memory settings, I don't think anything special will be needed at the level of the server.

[@tobias4096]

One question regarding the async on ngOnInit: Won't using async here allow e.g. afterViewInit to run before you can be sure onInit is done?

[@AngularUniversity]

If you need to, you can add logic on ngOInit without async, and have it call an async function, that works too.

[@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

[@AngularUniversity]

It's just Javascript. 😉 You can use async/await with Angular as well, it's fully supported. 👍

[@seanszarkowicz2910]

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

[@AngularUniversity]

I like that approach that you suggest, it's what I use now. You can already use Promises in Angular to do HTTP, no need to wait for a future version. 👍

[@seanszarkowicz2910]

@@AngularUniversity Yea I cant find where its documented anywhere on the Angular docs, so it makes it seems like its not the "Angular Way" - does your way work with HTTP Interceptors? I have been trying to put together some best practice / examples using Fetch with Angular and Signals or NgRx Signal store in the last couple days when I saw your video. Also trying to have examples working with HTTP Error Handlers. My goal is to keep things as simple as possible with HTTP Fetch. Do you have the example you use for HTTP Fetch with Async / Await?

[@PlerbyMcFlerb]

​@@seanszarkowicz2910if you wrap your method calls on the httpclient in firstvaluefrom, then the interceptors should work fine.

[@seanszarkowicz2910]

​@@PlerbyMcFlerbthanks for suggestion. yea but im trying not to have to do that sorta thing

[@MaximShiryaevT]

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.

[@AngularUniversity]

I agree, using Observables in the HTTP client was not the best move ever, Promises are a better fit for HTTP, especially with async/await. The new way of doing things in Angular is way easier, just wrap the data in a signal, but other than that it all works almost as we are using plain member variables.

[@stephendebeauchamp356]

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

[@AngularUniversity]

There is nothing to explain, it' trivial. Angular is making RxJs optional, you should prepare for a future with way less RxJs, if any at all.

[@user-qv4hn6qq4n]

But I don't like promises anymore 😁

[@AngularUniversity]

RxJs will become optional in Angular in the future, so it's important to revisit them. Don't worry, they are way easier than Observables.

[@KostasOreopoulos]

I think he does not like non programming promises. It was figurative speech

[@AngularUniversity]

@@KostasOreopoulos 😂😉

[@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

[@AngularUniversity]

It's a beginner myth that things need to be complicated in order to be "right." For most applications for the typical HTTP code, promises are a much better fit. Getting the job done in the simplest way possible is what keeps a codebase maintainable in the long run.

[@TimurMishagin]

Can totally agree with that 👍

[@gleitonfranco1260]

Intellij highly dark theme ❓😲

[@AngularUniversity]

Yes it's the high contrast theme, not Darcula 👍

[@g-luu]

I wouldn’t recommend anyone using angular to go the promise route. A lot of enterprise applications almost never use this approach. Keep it on personal projects like hobby projects i would say.

[@AngularUniversity]

Promises are standard in the enterprise for React or Node code, or just about anything else besides Angular. They work in Angular just as well.

[@DuzyKucyk22]

Vasco, I cannot believe that after learning angular from your great courses, and it's been like angular 6, I finally can disagree with or question your video. My feelings are that on the enterprise level, where everything is ngrx, you can forget promises even exist.

[@alessandroaprile181]

mmm... i feel very confusing and unclean to use a second paradigm, promise, just to cover a particular case when rxjs already covers it..

[@AngularUniversity]

It's much easier to use, in general you can use Promises for most cases when it comes to HTTP. Using RxJs everywhere is like trying to use just a hammer to fix everything around the house. We have other tools on our toolbox that are much more suited for the job at hand 👍

[@alessandroaprile181]

@@AngularUniversity well ok, _if you don't need the hammer already_. But if the complexity of your app is so low you don't need rxj, better use react.

[@alessandroaprile181]

@@AngularUniversity i mean, ok of you need to exclude rxjs from the Build, but if you already had it, why don't use It at fullest?

[@AngularUniversity]

@@alessandroaprile181 React can be used to build apps as complex as Angular. The right tool for the job, it's all I'm saying in the video.

[@AngularUniversity]

@@alessandroaprile181 You can have multiple tools in your toolbox, use the most appropriate depending on the situation. You would use a hammer to fix a watch. 😊😉I understand where you come from, but it's mostly a myth.