Transcript from the "Lifecycle Hooks" Lesson
>> Lukas Ruebbelke: Now, I did mention that there are things that are happening with the very stages of a component. And for instance,
>> Lukas Ruebbelke: An anti-pattern in Angular is to have complex construction logic, or logic in the constructor. And this is actually an anti-pattern across the board. The reason being is, how do you call the constructor on a class?
[00:00:25] You don't. It's implicitly called. And so now you're basically tucking logic into something that you can't explicitly call. It's now essentially coupled to this implicit method that you can't directly call. In Angular specifically, is if you are binding to something on the template that the parent component is supplying, that may or may not exist.
[00:00:52] So what will happen is you say, okay, I need items from my parent component. Well, if it's an asynchronous call, that still may be end route, and so it may be a second or two. When is a constructor called? [SOUND] Immediately, the minute you do something up, [SOUND] that constructor is called.
[00:01:12] And so you will run into a problem where if you assume data is available via binding for the parent component, and you put in your constructor, you're going to realize very quickly that it may actually work a few times. And then you have a slow Internet connection, and it's not there.
[00:01:30] So what you do is you pull that out of the constructor, and you put it into, for instance, ngOnInit. And that's when you know safely that the bindings have been satisfied and you can assume that it's there. You can safely operate on it. And so this is an example of a lifecycle hook in action.
[00:01:51] So here's a list of all the available lifecycle hooks.
>> Lukas Ruebbelke: What you will use, and every one of these has its utility. But to simplify it, these are the two that you'll use most of the time. And oftentimes, if my component is for the most part stateless, I won't even use ngOnDestroy.
[00:02:18] Cuz it's very good about cleaning up after itself. But you will use ngOnInit quite frequently. And so these are here. I wouldn't worry about them. The big ones, it's just, no. Init and destroy, it's alive, it's dying.
>> Lukas Ruebbelke: And so here.
>> Lukas Ruebbelke: The question is can ngOnInit fail too, if you had really bad luck?
[00:02:49] Well, I think that depends on [LAUGH] what do you mean by really bad luck? Was there an earthquake and your computer exploded? Then possibly. In terms of referencing data, that ngOnInit is not fired until ngOnChanges is fired at least once. What that means is that anything you're referencing via binding, is being called.
[00:03:15] And so basically you're binding has been satisfied. So I don't wanna say never, and I don't wanna try to quantify or say, what is bad luck? But as a whole, I would be willing to put 100 bucks on the fact that it's going to work. If I'm depending on data from binding, it's going to exist on the ngOnInit block.
>> Lukas Ruebbelke: So you can use ngOnInit or lifecycle hook without an interface. But it's considered best practice to do so. The reason being is because you are formalizing your contract with the component. And so it also tells your IDE that this is what's happening. So it's kinda like putting a ring on it, if you will.
[00:04:03] I'm committed to OnInit, and therefore, I will call or satisfy this interface.