Absolutely 🎉😊 It's such a breath of fresh air compared to other more complicated approaches, isn't it? But you wouldn't believe the amount of people that thinks that async/await doesn't even work in Angular, or that it shouldn't be used because of a variety of reasons. I'm very glad to hear that more people are adopting it 😉
Yes it works on the resolver great, but notice that you can also call an async method from ngOnInit and have it load the data. In certain situations where we want to quickly load the screen and show something to the user this might be an option, but usually I agree a resolver is the best way to load the initial data. 👍
@@AngularUniversity- ngOnInit will not wait for an async to finish even when you use async, you need to load it before the component... resolvers are the correct way in that case
@@jonathangamble Correct it will not wait I know. The result of ngOnInit is ignored even if it's a promise, and calling a async method from ngOnInit will not block the process. But that is a good thing for what we want to do in certain cases. We just want the page to load ASAP and show multiple smaller loading local loading indicators inside the page, that each load certain data. Imagine a dashboard with multiple sections each with it's own loading indicator. you can do it either way, depending on the user experience that you are aiming for.👍
You're welcome, I'm very happy to share this and I hope the Angular community will consider different approaches to building applications, and async / await is an important ingredient for that 😊
Yes me too, it's crazy that this video is even necessary 😊 I got RxJs fans on Twitter telling me that it causes race conditions, writing posts saying that it doesn't work because it's not compatible with Zones. 🤣
Correct, that is a feature that is not very well known, async pipe does support Promises 😊 Yes I agree, indeed there is nothing wrong with using them. 👍😉
@@AngularUniversity So something that I'm wondering about AsyncPipe is, it uses "markForCheck" method, when a new value is emitted; So, if promises weren't changed to generators, or for an observable that reacts to something outside zone.js, AsyncPipe actually wouldn't trigger change detection, right? Which means it doesn't help regarding events happening outside zone.js/ngZone.
I thought so too, thank you for confirming @Johan 😊, and is the plugin on by default in Nx, or do you have to configure it manually? With the Angular CLI i't's on by default, no special configuration is needed. 👍
For example, the Supabase documentation for Angular projects uses async/await heavily. It was something I had to get comfortable with. I did convert all to use rxjs, though, you'd probably tell me that is overkill now haha.
Awesome résumé of this feature, and great talk with Mathieu 👍😎 Thanks Vasco And I agree with you about the next phases of Angular and zoneless, it will allow some native JavaScript uses like this one.
A lot of our code base is either ngrx or observable services, i think we could still utilise async await for Post/Put/Delete verbs when updating something on the back end. but retrieving data wiloukd atill use observables.
Hi Adam, I think that is very good start, async/await works especially well indeed for modification operations. 👍 For reads also works very well, you can read it and then emit it via an Observable is you are using RxJs, it's no problem. 👍 Or even save the data in a member variable and access it directly from the template, it all works great 😉
Hello, very good video! Starting with angular 16, in the chrome debug, the "this" context inside an async function always turns out to be undefined. What is the reason?
Although the async/await approach makes your code much easier to understand I'm trying to get my head around how you would implement a typical API call that requires behaviour that RXJS provides such as debounce, distinct and switchMap without needing to reinvent RXJS which seems to defeat the object?
This is mentioned a lot, but the reality is that the vast majority of API calls don't need those features. You just make the call, get the data, handle an error and that's it. It's true that RxJs can be used for those cases, but if we don't need those features then why use RxJs? It's like hunting kittens with a tank 😉 The right tool for the job and minimizing unncessary complexity it's all i'm saying 👍
@@AngularUniversity I like the "killing kittens with a tank" phrase 😂😂 OK I take your point so we simply use firstValueFrom to convert our Observable HTTP request to a promise and implement a boolean that manages whether a call is in progress to prevent multiple calls to the API due to an impatient user or a fast double click?
@@andyhb1970 😉 Yes, as simple as that. 😊 You can create a global user indicator, or even turn it on via an HTTP interceptor so that you don't have to add those loading flags everywhere. Here is an implementation with an interceptor, you can even turn it off selectively - blog.angular-university.io/angular-loading-indicator/👍
That is a very good question. 👍You can use the Angular HTTP Client with async / await simply by converting the returned Observable into a Promise using firstValueFrom(), check this video on more details ruclips.net/video/kTsVzAqX2wc/видео.html 👍 If you do this, HTTP interceptors will work great, it's what I do on my code bases lately. The code is very readable and simple, especially if you return Promises instead of Observables from your HTTP service layer. The APIs of Angular will be revisited in the near future to make RxJs optional, and this means that the HTTP client API will be one of the APIs to be reviewed. We don't know yet what it will look like, but meanwhile this solution works very well. 😊
Yes, it works great doesn't it? 😊 It's amazing so many people think it's broken by some reason. I've seen GDEs writing blog posts saying that it doesn't work. Some myths are so powerful 😂
Great question, Signals is independent of the 2, signals track state. Async/await is a simplified way to handle async operations, very commonly used in other frameworks.RxJs will become optional in the future for Angular, so it's nice as a developer to be aware of alternatives, and async await is an important tool to learn as more projects are starting to use it. 👍
That's a great question, I think so, that it does. A,d the argument of consistency doesn't hold water to me. I suggest to use promises and async /await for plain HTTP code that does not need any event orchestration. Just pulling data out of the database, saving, displaying an error. No need for RxJs for that, that's clear; For special cases that do need orchestration, only then use it; Those are few and far between, if they even occur at all for many applications. Let's use the right tool for the job, no need to go around hunting kittens with a tank. 😉
@@AngularUniversity thank you for your answer. For me it is not (only) a matter of consistency but also how I handle and pass data throughout the application. Using Observables or now Signals works really well with a functional and declarative coding style, but I am not sure how it would look like with the async/await syntax. Also how does it work with onPush? You just mentioned that it works in the video PS: great image with the kitten and the tank :D
@@boris8983 There is nothing special about the syntax and OnPush, with OnPush you need to push the data to the component after fetching it from the backend via for example async/await. The code that we manage to write with RxJs is not really fully declarative, it's a mix between declarative and imperative. If you use async/await for most async operations and signals for reactivity, it will also be a mix between declarative and imperative, but just easier to read for most developers. If you don't know almost anything about async/await you will be able to read a code base written with it without any problem, that's it's big advantage.👍
Thank you Vasco for your great explanation on this patterns. Can i ask one thing with you. Which method are you suggesting to use in real world application. async/await or Rxjs-Observable.? Looking forward to your advice on this. Thank you.!!
Personally I have switched since over a year my whole team to to async/await and Promises, and we never looked back. We only use RxJs in places where we really need to, which is almost never, and things have never worked better. 👍
Hi Mustafa, actually no not really, you don't need to change the target you can keep it as it is. Instead, the CLI uses a plugin that ensures that async/await is converted into something else in production that is compatible with zones. So if you use the CLI, no action is needed; It seems like Nx supports it too. 😊
I know that is presented as an argument continuously. But it's not because RxJs is a good fit for making a search combobox that we need to write everything using it. In the vast majority of cases, there is nothing to cancel or orchestrate. We just pull data out of the database, show it in a table, save it back. Cancellation is an extremely rare use case. If really needed, yes you can do it with Promises and async/await too, or with a promise-based library like tRPC for example.
Does it block the ui if the api is slow? Part of the beauty of using rxjs can have multiple components load different apis and that component shows up on the screen when they're done loading rather than waiting for everything to resolve
Great question, it doesn't block the UI, but it can if you want to. You can either block the UI with a loading indicator, or do the request in the background and update the UI when done. But the async feature itself does not block anything, it's fully asynchronous. You can launch multiple requests in parallel with Promise.all(). It's a tradeoff when compared to RxJs. Async /await does very well the typical everyday use cases, RxJs is good for much more advanced scenarios, it's a matter of using the right tool for the job. 👍 Personally for every day HTTP operations like pulling data from a backend and showing it to the user, my team has been using async await for a while now and with great results, the code is way simpler to read and I get way less review issues, I need to give much less developer support, etc. 😊
@@seanszarkowicz I did a video showing how to use with the Angular HTTP client. I could do it but there is nothing much to show. I might still do it I've added it to the list, thank you for the idea. 👍
Great question, I personally use the CLI, but I bet Nx also has full support for async/await, and it either uses internally the exact same bable plugin, or something very similar. If you find confirmation, please share it here in the comments, but I cannot imagine that it would be otherwise. 😉
Async / await solves callback hell very elegantly. It reads just like synchronous code. Your code remains flat. RxJs is still a good fit for certain use cases, it's not going away. But it will become optional, so I think it's important as an Angular developer to also know async/await, as more and more projects are starting to use it.
@@AngularUniversity You can create excellent code using async/await, but it's questionable whether someone who isn't proficient in RxJs would utilize async/await effectively. This could lead to callback hell and potentially excessive individual awaits instead of properly grouping them. Employing RxJs not only enhances code readability but also mitigates the risk of encountering these issues.
in most languages, async/await solves the problem of callback hell, thus making the code simpler and easier to read. same here. can you misuse it? sure, just like any other tool, be it promises or rxjs.
I'm agree that Rxjs is Nice, but in some cases, have 3 switchMap and 5 operators in one Pipe is not the better options, async/await helps in that cases, @AngularUniversity has an excellent video regarding that subject, i recommend you to watch it
I feel the view of callback hell just referring to the level of nesting and indentation is missing the primary issue, which is uncoordinated asynchrony, ie race conditions. It is a more fundamental issue than just 'readability.' In the wrong hands async await can lead to uncoordinated buggy inscrutible spaghetti Granted it does ultimately boil down to a skill issue and I love async await for many tasks.
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
Enjoy everyone, let me know if you plan on using async/await in your Angular applications?
Great one, and i totally push for using async await as much as possible. Simpler and more readable code!
Absolutely 🎉😊 It's such a breath of fresh air compared to other more complicated approaches, isn't it? But you wouldn't believe the amount of people that thinks that async/await doesn't even work in Angular, or that it shouldn't be used because of a variety of reasons. I'm very glad to hear that more people are adopting it 😉
For loading before a component, it is important to note that async await should be in the resolver
Yes it works on the resolver great, but notice that you can also call an async method from ngOnInit and have it load the data. In certain situations where we want to quickly load the screen and show something to the user this might be an option, but usually I agree a resolver is the best way to load the initial data. 👍
@@AngularUniversity- ngOnInit will not wait for an async to finish even when you use async, you need to load it before the component... resolvers are the correct way in that case
@@jonathangamble Correct it will not wait I know. The result of ngOnInit is ignored even if it's a promise, and calling a async method from ngOnInit will not block the process. But that is a good thing for what we want to do in certain cases. We just want the page to load ASAP and show multiple smaller loading local loading indicators inside the page, that each load certain data. Imagine a dashboard with multiple sections each with it's own loading indicator. you can do it either way, depending on the user experience that you are aiming for.👍
Another great video Vasco! I love the async/await pattern (so much better than a chain of promises),
Thank you Robert, I'm happy to happy to hear that. 😊 Totally agree, for the most common every day scenarios, I think it's the right tool for the job 👍
Thank you, thank you, thank you for getting the word out!
You're welcome, I'm very happy to share this and I hope the Angular community will consider different approaches to building applications, and async / await is an important ingredient for that 😊
I've been using async/await in Angular for years. :D
Yes me too, it's crazy that this video is even necessary 😊 I got RxJs fans on Twitter telling me that it causes race conditions, writing posts saying that it doesn't work because it's not compatible with Zones. 🤣
AsyncPipe supports promises as well, so there is nothing wrong using them instead of Observables
Correct, that is a feature that is not very well known, async pipe does support Promises 😊 Yes I agree, indeed there is nothing wrong with using them. 👍😉
@@AngularUniversity So something that I'm wondering about AsyncPipe is, it uses "markForCheck" method, when a new value is emitted;
So, if promises weren't changed to generators, or for an observable that reacts to something outside zone.js, AsyncPipe actually wouldn't trigger change detection, right?
Which means it doesn't help regarding events happening outside zone.js/ngZone.
Works with NX as well indeed if you are mindful of the babel plugin.
I thought so too, thank you for confirming @Johan 😊, and is the plugin on by default in Nx, or do you have to configure it manually? With the Angular CLI i't's on by default, no special configuration is needed. 👍
@@AngularUniversity hi Vasco, it’s on by default.
For example, the Supabase documentation for Angular projects uses async/await heavily. It was something I had to get comfortable with. I did convert all to use rxjs, though, you'd probably tell me that is overkill now haha.
If it works it works 😉But I encourage you to try other patterns for building Angular applications, RxJs is not the only way. 👍
Excelllent video as always 🎉🎉🎉🎉
Thank you, I'm happy to hear that. 😊
Awesome résumé of this feature, and great talk with Mathieu 👍😎 Thanks Vasco
And I agree with you about the next phases of Angular and zoneless, it will allow some native JavaScript uses like this one.
Thank you Alain, I was very happy to see this confirmed too. 😉 Zoneless is going to be awesome, first though, signals:true 😉
A lot of our code base is either ngrx or observable services, i think we could still utilise async await for Post/Put/Delete verbs when updating something on the back end. but retrieving data wiloukd atill use observables.
Hi Adam, I think that is very good start, async/await works especially well indeed for modification operations. 👍 For reads also works very well, you can read it and then emit it via an Observable is you are using RxJs, it's no problem. 👍 Or even save the data in a member variable and access it directly from the template, it all works great 😉
Hello, very good video!
Starting with angular 16, in the chrome debug, the "this" context inside an async function always turns out to be undefined. What is the reason?
Although the async/await approach makes your code much easier to understand I'm trying to get my head around how you would implement a typical API call that requires behaviour that RXJS provides such as debounce, distinct and switchMap without needing to reinvent RXJS which seems to defeat the object?
This is mentioned a lot, but the reality is that the vast majority of API calls don't need those features. You just make the call, get the data, handle an error and that's it. It's true that RxJs can be used for those cases, but if we don't need those features then why use RxJs? It's like hunting kittens with a tank 😉 The right tool for the job and minimizing unncessary complexity it's all i'm saying 👍
@@AngularUniversity I like the "killing kittens with a tank" phrase 😂😂 OK I take your point so we simply use firstValueFrom to convert our Observable HTTP request to a promise and implement a boolean that manages whether a call is in progress to prevent multiple calls to the API due to an impatient user or a fast double click?
@@andyhb1970 😉 Yes, as simple as that. 😊 You can create a global user indicator, or even turn it on via an HTTP interceptor so that you don't have to add those loading flags everywhere. Here is an implementation with an interceptor, you can even turn it off selectively - blog.angular-university.io/angular-loading-indicator/👍
i thought you couldn’t use interceptors with async await for http requests? isn’t that a huge downside vs rxjs?
That is a very good question. 👍You can use the Angular HTTP Client with async / await simply by converting the returned Observable into a Promise using firstValueFrom(), check this video on more details ruclips.net/video/kTsVzAqX2wc/видео.html 👍 If you do this, HTTP interceptors will work great, it's what I do on my code bases lately. The code is very readable and simple, especially if you return Promises instead of Observables from your HTTP service layer. The APIs of Angular will be revisited in the near future to make RxJs optional, and this means that the HTTP client API will be one of the APIs to be reviewed. We don't know yet what it will look like, but meanwhile this solution works very well. 😊
Using right now, works fine
Yes, it works great doesn't it? 😊 It's amazing so many people think it's broken by some reason. I've seen GDEs writing blog posts saying that it doesn't work. Some myths are so powerful 😂
Why do you need async/await if there are rxjs and signals?
Good question.
Great question, Signals is independent of the 2, signals track state. Async/await is a simplified way to handle async operations, very commonly used in other frameworks.RxJs will become optional in the future for Angular, so it's nice as a developer to be aware of alternatives, and async await is an important tool to learn as more projects are starting to use it. 👍
It's always good to have multiple options to do different tasks. Async await is a tool, and no tool is supposed to answer all use cases.
@@AlainBoudard I agree, the right tool for the job it's what its all about. 😉
Simplicity. RxJs is actually a more powerful api (superset) but you often don't need that power, but you get the complexity either way.
Does it make sense to use Promises AND Observables? I think you should use either one or the other but not both
That's a great question, I think so, that it does. A,d the argument of consistency doesn't hold water to me. I suggest to use promises and async /await for plain HTTP code that does not need any event orchestration. Just pulling data out of the database, saving, displaying an error. No need for RxJs for that, that's clear; For special cases that do need orchestration, only then use it; Those are few and far between, if they even occur at all for many applications. Let's use the right tool for the job, no need to go around hunting kittens with a tank. 😉
@@AngularUniversity thank you for your answer. For me it is not (only) a matter of consistency but also how I handle and pass data throughout the application. Using Observables or now Signals works really well with a functional and declarative coding style, but I am not sure how it would look like with the async/await syntax.
Also how does it work with onPush? You just mentioned that it works in the video
PS: great image with the kitten and the tank :D
@@boris8983 There is nothing special about the syntax and OnPush, with OnPush you need to push the data to the component after fetching it from the backend via for example async/await. The code that we manage to write with RxJs is not really fully declarative, it's a mix between declarative and imperative. If you use async/await for most async operations and signals for reactivity, it will also be a mix between declarative and imperative, but just easier to read for most developers. If you don't know almost anything about async/await you will be able to read a code base written with it without any problem, that's it's big advantage.👍
Thank you Vasco for your great explanation on this patterns. Can i ask one thing with you. Which method are you suggesting to use in real world application. async/await or Rxjs-Observable.?
Looking forward to your advice on this. Thank you.!!
Personally I have switched since over a year my whole team to to async/await and Promises, and we never looked back. We only use RxJs in places where we really need to, which is almost never, and things have never worked better. 👍
@@AngularUniversity thank you so much for this advice.🫂🤝
so ZOne js and zones are used by Angular for Change detections?
Yes, Zones are used by default change detection, correct. 👍
So what i understand the target should always
Hi Mustafa, actually no not really, you don't need to change the target you can keep it as it is. Instead, the CLI uses a plugin that ensures that async/await is converted into something else in production that is compatible with zones. So if you use the CLI, no action is needed; It seems like Nx supports it too. 😊
And what about HTTP interceptors? :)
You can still use the HTTP client with async/await, I will show that in some future video. 👍
can you cancel ongoing http requests with async/await? with rxsj you can call switchMap on that.
I know that is presented as an argument continuously. But it's not because RxJs is a good fit for making a search combobox that we need to write everything using it. In the vast majority of cases, there is nothing to cancel or orchestrate. We just pull data out of the database, show it in a table, save it back. Cancellation is an extremely rare use case. If really needed, yes you can do it with Promises and async/await too, or with a promise-based library like tRPC for example.
Does it block the ui if the api is slow?
Part of the beauty of using rxjs can have multiple components load different apis and that component shows up on the screen when they're done loading rather than waiting for everything to resolve
Great question, it doesn't block the UI, but it can if you want to. You can either block the UI with a loading indicator, or do the request in the background and update the UI when done. But the async feature itself does not block anything, it's fully asynchronous. You can launch multiple requests in parallel with Promise.all(). It's a tradeoff when compared to RxJs. Async /await does very well the typical everyday use cases, RxJs is good for much more advanced scenarios, it's a matter of using the right tool for the job. 👍 Personally for every day HTTP operations like pulling data from a backend and showing it to the user, my team has been using async await for a while now and with great results, the code is way simpler to read and I get way less review issues, I need to give much less developer support, etc. 😊
@@AngularUniversity do you have plans to do a real basic video on using async / await with native FETCH as well as using interceptors ?
@@seanszarkowicz I did a video showing how to use with the Angular HTTP client. I could do it but there is nothing much to show. I might still do it I've added it to the list, thank you for the idea. 👍
Can you make a video on angular signal store and firebase
Thank you for the suggestion 😊
Could you share that PR please ?
No problem, it's this one, I will add it to the description too 😊 github.com/stackblitz/starters/pull/24
So, it's ok to use async/await if you're using cli, and what about nx?
Great question, I personally use the CLI, but I bet Nx also has full support for async/await, and it either uses internally the exact same bable plugin, or something very similar. If you find confirmation, please share it here in the comments, but I cannot imagine that it would be otherwise. 😉
@@AngularUniversityI can confirm it works with NX
Ad i know nx use also the ng cli to build the angular application. Nx cli is as big wrapper and will delegate to the right cli
🎉🎉
😉😉
Sure let's use async/await and bring back callback hell... RxJs is just better.
Async / await solves callback hell very elegantly. It reads just like synchronous code. Your code remains flat. RxJs is still a good fit for certain use cases, it's not going away. But it will become optional, so I think it's important as an Angular developer to also know async/await, as more and more projects are starting to use it.
@@AngularUniversity You can create excellent code using async/await, but it's questionable whether someone who isn't proficient in RxJs would utilize async/await effectively. This could lead to callback hell and potentially excessive individual awaits instead of properly grouping them. Employing RxJs not only enhances code readability but also mitigates the risk of encountering these issues.
in most languages, async/await solves the problem of callback hell, thus making the code simpler and easier to read. same here. can you misuse it? sure, just like any other tool, be it promises or rxjs.
I'm agree that Rxjs is Nice, but in some cases, have 3 switchMap and 5 operators in one Pipe is not the better options, async/await helps in that cases, @AngularUniversity has an excellent video regarding that subject, i recommend you to watch it
I feel the view of callback hell just referring to the level of nesting and indentation is missing the primary issue, which is uncoordinated asynchrony, ie race conditions. It is a more fundamental issue than just 'readability.' In the wrong hands async await can lead to uncoordinated buggy inscrutible spaghetti
Granted it does ultimately boil down to a skill issue and I love async await for many tasks.