Menu
Angular provides lifecycle hook ngOnInit() and ngOnChanges() by default. Why should ngOnInit be used, if we already have a ngOnChanges? And constructor also.
986
ngOnChanges vs ngOnInit Remember that ngOnChanges is specific to bound inputs on the component. This means if you don't have any @Input properties on a child, ngOnChanges will never get called. ngOnInit is specific to the component being initialized. ngOnChanges is specific to @Input properties on a child component.
Called before ngOnInit() (if the component has bound inputs) and whenever one or more data-bound input properties change. NOTE: If your component has no inputs or you use it without providing any inputs, the framework will not call ngOnChanges() .
The constructor is a Typescript feature used to instantiate the Typescript class. In most Angular projects about the only thing that should ever be done in the constructor is to inject services. The ngOnInit function is specific to the Angular framework and is called when Angular is done creating the component.
ngOnInit() called by Angular to indicate that Angular is done with initializing the component. To use ngOnInit() we have to import OnInit from @angular/core (Actually it is not required but as a good practice import the OnInit ) Whenever you create a new component using angular-cli ngOnInit being added by default.
The ngOnChnages is a life cycle hook, which angular fires when it detects changes to data-bound input property. This method receives a SimpeChanges object, which contains the current and previous property values.
The reason we use ngOnInit and not ngOnChanges to initialise a component is that ngOnInit is only called once whereas ngOnChanges is called for every change to the input properties.
To keep it very short.
ngOnInit() is used to execute any piece of code for only one time (for eg : data fetch on load).
ngOnChanges() will execute on every @Input() property change.
If you want to execute any component method, based on the @Input() value change, then you should write such logic inside ngOnChanges().
As you claim why do we need ngOnInit() when we have ngOnChanges(), it is because you cannot execute one time code, on every @Input() property change. And you cannot use constructor as the replacement of ngOnInit() as well. Because the bindings, such as @Input properties are not available within the constructor.
I think you will get fair idea with this Diff between OnInit and constructor
89
How a form need be setup
0. Static design Html markup should hold how the design is structured and laid out. Any permanent classes are to be applied directly in markup.
1. Constructor
Setup dependencies, like services, providers, configuration etc. These enable the component to manage itself along with interact with other elements.
2. Initializer (ngOnInit)
Populates form elements like dropdowns etc when their values are to be retrieved from external source, rather than being known at design time. This is to be done once only to setup the initial rendering of the form
3. Input changes (ngOnChanges)
Runs on every change on any input, and perform any action which gets triggered by that particular control. For example, if there are multiple inputs and on any validation failure on a single one, you need to focus on the failed control and disable all others, you can do it here. Useful for validation logic.
Not to be used to handle other control's layout and structure.
This often runs recursively if one control impacts others so logic has to be carefully designed.
If you want to prevent this from running, you can disable the Angular change detection and manually handle the state yourself.
4. Control's event handlers Here you take in the final value of the control and use it to perform manipulation of other controls in the form. As soon as you change the value of other controls, the ngOnChanges event fires again.
12
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
