I’m currently evaluating the pros ‘n’ cons of replacing Angular’s resp. RxJS’ Observable
with plain Promise
so that I can use async
and await
and get a more intuitive code style.
One of our typical scenarios: Load some data within ngOnInit
. Using Observables
, we do:
ngOnInit () { this.service.getData().subscribe(data => { this.data = this.modifyMyData(data); }); }
When I return a Promise
from getData()
instead, and use async
and await
, it becomes:
async ngOnInit () { const data = await this.service.getData(); this.data = this.modifyMyData(data); }
Now, obviously, Angular will not “know”, that ngOnInit
has become async
. I feel that this is not a problem: My app still works as before. But when I look at the OnInit
interface, the function is obviously not declared in such a way which would suggest that it can be declared async
:
ngOnInit(): void;
So -- bottom line: Is it reasonable what I’m doing here? Or will I run into any unforseen problems?
But if you see carefully there is no one awaiting ngOnInit and you can't await ngOnInit even if you wanted to. It will run the async function but it WILL NOT await for it to complete, it just allows you to use the await keyword, but it is not a aysnc function, despite having the async keyword.
Using Async/Await in Angular Basically, Async/Await works on top of Promise and allows you to write async code in a synchronous manner. It simplifies the code and makes the flow and logic more understandable.
It makes asynchronous code look more like synchronous/procedural code, which is easier to understand. await can only be used in async functions. It is used for calling an async function and waits for it to resolve or reject. await blocks the execution of the code within the async function in which it is located.
Asynchronous functions are prefixed with the async keyword; await suspends the execution until an asynchronous function return promise is fulfilled and unwraps the value from the Promise returned.
It is no different than what you had before. ngOnInit
will return a Promise and the caller will ignore that promise. This means that the caller will not wait for everything in your method to finish before it proceeds. In this specific case it means the view will finish being configured and the view may be launched before this.data
is set.
That is the same situation you had before. The caller would not wait for your subscriptions to finish and would possibly launch the app before this.data
had been populated. If your view is relying on data
then you likely have some kind of ngIf
setup to prevent you from accessing it.
I personally don't see it as awkward or a bad practice as long as you're aware of the implications. However, the ngIf
can be tedious (they would be needed in either way). I have personally moved to using route resolvers where it makes sense so I can avoid this situation. The data is loaded before the route finishes navigating and I can know the data is available before the view is ever loaded.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With