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?
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.