Open DmitryEfimenko opened 6 months ago
I think this practice should be called "Don't put component logic in the constructor" instead.
component logic is perfectly fine in a constructor.
ngOnInit
has been promoted as the way-to-go but the only benefit is being able to deal with @Input
.
Using a constructor to populate a form with the response of an API call based on a route param is perfectly fine.
However, as pinpointed by @DmitryEfimenko, this practice is not a 'best one'. I'll remove it.
@geromegrignon in my opinion it’s not a place for that, because constructor fires when Angular constructs component tree, so the DOM element of form could be not ready.
Or I’m missing something 🤔
The DOM is initialized after ngOnInit
is triggered: how would it help?
Populating the variable/AbstractControl of a form is unrelated at updating the DOM for it.
I'll remove this item: It will require a full rewrite, more related to: 'how to init logic in a component'.
put init logic in the ngOnInit lifecycle hook is not the best practice.
Please have a look at this article on AngularInDepth