Generally ngOnInit() is used to set input properties when the component initialized. Similarly can we set the same input properties in ngAfterViewInit() instead of ngOnInit() ?. Can we implement all those operations on ngAfterViewInit() which we usually do under ngOnInit()?
The above question was asked in an interview and I want to understand will it be possible or not.
If Yes/No, can you explain with any example?
Thank you.
In some marginal (and not so useful) cases, Angular lifehooks can be used to perform the same operations, but mainly they are intended to control and handle different operations.
Not going into details of lifehooks here, but ngOnInit is fired well before ngAfterViewInit: so it can (and should) be used to handle properties and operations that the content and the view of the component might later depend on - like setting initial values (that were not set in the constructor or as class members) or subscribing to services etc.
On the other hand, ngAfterViewInitwill fire when the component's view is fully loaded/populated, so it will fire after all the child components and the view directives are loaded. Thus, the ngAfterViewInit lifehook is the place to handle operations and properties on which the view elements depend or that view elements provide to the component. For example, if you need to perform operations on the DOM elements (that are not initialized at the time of ngOnInit firing): access/alter the css properties, calculate some widths, heights, offsets, deal with the variables from loaded children components etc.
Another important difference to keep in mind is that - as you use your app, move through pages, etc. - the individual components' ngOnInit will fire only once (if it's not subsequently destroyed, which will allow it to re-initialize), when the component is initialized, but ngAfterViewInit will fire each time you get back to that component (when it re-renders the view). Because of that, ngAfterViewInit is also a good place to handle operations that are tied to re-rendering the view, like handling the load of random image in the background each time a user opens that page.
When deciding where to put the operations, one should know exactly why he/she is doing that in the given lifehook instead of the other - and why and how it affects the lifecycle of the app.
For example, if your view content depends on some data you get from API subscription, you can subscribe to the service in your ngAfterViewInit (and unsubscribe later!), but the downside is that your view will be rendered before your subscription's response comes in - because this lifehook is triggered when the view is already there. If you didn't handle the view elements keeping that time-difference in mind, your view might not work as intended and might even break with errors.
In general, since ngAfterViewInit comes after ngOnInit, you are (usually) quite safe to use ngOnInit to handle operations that view elements will depend on (just don't try to access them - they are not yet present).
In a nutshell: if you handle your view well, you can put some of the (predominantly meant for) ngOnInit operations into ngAfterViewInit, but you would need a good reason and think about functionality. It's much safer to keep those lifehooks and their logic apart and use them to handle operations they're intended for.