This course has been updated! We now recommend you take the Complete Intro to React, v7 course.

Check out a free preview of the full Complete Intro to React, v2 (feat. Router v4 and Redux) course:
The "React Lifecycle Methods" Lesson is part of the full, Complete Intro to React, v2 (feat. Router v4 and Redux) course featured in this preview video. Here's what you'd learn in this lesson:

Brian introduces the React Lifecycle Methods. These are methods that are called at different stages throughout a component’s life in an application. One of the most common uses for these methods is to be able to request remote data as soon as a component is mounted. Brian spends a few minutes talking about these methods and how he typically uses them.

Get Unlimited Access Now

Transcript from the "React Lifecycle Methods" Lesson

>> Brian Holt: So let's go back to details. We've gone this entire class, we haven't talked about actually one of the more fundamental core concepts to react, which is the life cycle methods. And we've dealt with one of them, which is get initial state, which is whenever you first create a component, one of the first methods it calls is get initial state.

[00:00:21] There's actually a couple other steps in its lifecycle of a component that you can hook into to do very interesting things. So the first one definitely is getInitialState, that's gonna be the first one /constructor if you're using ES6 classes. The next one is called componentWillMount which gets called right before your component gets put into the DOM.

[00:00:44] So if you need to do anything before it's put into the DOM, this is the place that you would typically do it. I will say that I almost never use componentWillMount. That's usually not useful to me. The one that I use a lot and you will use a lot is componentDidMount.

[00:01:00] So you call it right after it gets put onto the DOM. OK so component did mount. That gets called right after it gets put into the DOM. Now this is useful because we're gonna talk about universal server side rendering of react. You can render your app entirely on your node server and then send down the complete mark up.

[00:01:20] Supercool and it's actually not super difficult to do. The nice thing is that componentWillMount, if anything needs to get run also in the node environment, you put it in componentWillMount cuz componentWillMount does get called in the node environments. ComponentWillMount does get called in the node environment. ComponentDidMount does not get called in the node environment.

[00:01:41] And I think that logically follows, right? It doesn't actually get put onto a DOM, so it never gets called. So, let's talk about the things that go into componentDidMount.
>> Speaker 2: We've actually done it before. Performance things, reasons for did mount over will mount?
>> Brian Holt: I can't think of any perf reasons that you would do it.

[00:01:59] Other than like, again if you didn't want to get called into the node environment. That's really the only consideration. But the thing that you can guarantee in componentDidMount is the browser, the browser DOM APIs are available, right? Because if it gets mounted into the DOM you can guarantee that the DOM isn't there, right?

[00:02:18] Whereas componentWillMount, you have no guarantee that the DOM is available. So anything that you have to interact with the DOM, right. For the most part, you don't directly want to interact with the DOM when you're working with React. You want React to interact with the DOM, and then you interact with React.

[00:02:32] That's generally the pattern. However this is web development, things are messy. Sometimes you just have to do things like that. So that's where you would do it, is componentDidMount. You do AJAX in componentDidMount because first of all you want to display something. They see something, whether that's a loading stage or something like that.

[00:02:52] So that's why you want to do an incomponented mount. You want to be able to see something and then once you actually have the data come back from AJAX then you display whatever you're looking for. So AJAX gets done in componentDidMount. If you need to integrate with jQuery we talked a little bit about doing jQuery.payments you would do that inside of componentDidMount.

[00:03:13] If you need to set up any side event listeners, which again, suck, but if you need to, you do that in componentDidMount.
>> Brian Holt: Yeah, if you're working with D3, you'll do a bunch of stuff in componentDidMount. So, as you can see, there's a bunch of uses for componentDidMount.

[00:03:31] That's why you often do have to use componentDidMount. And then the last one is componentWillUnmount. So, that's right before it leaves the DOM. And this is almost exclusively for cleanup, right? So, if you put any DOM listeners on, and you have to go remove them, or you have memory leaks, anything else that you need to do, that you need to clean up before you remove that component.

>> Speaker 2: If you are using something for like, a pub sub, is componentWillUnmount where you would want to have it like, stop listening?
>> Brian Holt: Yep, unsubscribe.
>> Speaker 2: Okay.
>> Brian Holt: Yep, absolutely.
>> Speaker 2: Sublime tool question.
>> Brian Holt: Yeah.
>> Speaker 2: Okay. They're not getting any auto completes for the HTML. Is that supposed to be included in that whole thing?

[00:04:17] So he needs another package?
>> Brian Holt: Yeah, I'm assuming, well, auto completes. It depends on what kind of auto complete you're talking about. If you're talking about emmet, specifically, there is some configuration to it. And there's a stack overflow question that I asked [LAUGH] that one of the authors of the packages comes and tells me how to get emmet to work.

[00:04:40] So I would recommend checking that out. For everything else, I think there's another package that someone else uses. And I don't recall what it is. [SOUND] But anyway, there's more configuration to be done. Unfortunately I don't remember what it is.
>> Brian Holt: Cool. Any questions so far about life cycle methods?

>> Brian Holt: So, there are a few others that are much more niche. There's like getDefaultProps if for whatever reason you needed default props. That's usually called at the root level of your application. This can be useful for things like dependency injection if you're into that. I am not so I typically don't but this is somewhere that you could do it.

[00:05:31] I don't believe I've actually ever shipped code with getDefaultProps. So that tells you how often it gets used. There is shouldComponentUpdate, which I do use occasionally. That's almost exclusively used for, I'm gonna say it's used exclusively for performance reasons. So the way that React tells if the component used a update is it looks at it's state.

[00:05:54] And if the state has not been modified from the last time it saw it, it says, cool nothing changed, I'm just not gonna even rerun the render method because none of the state changed. But let's say you have deeply nested data that has to go all the way in and check every tiny, little thing and then come all the way back out.

[00:06:12] Right? That's expensive as you might imagine. So if you're having a bunch of re-renders being called on deeply nested data, that's gonna be slow. It's gonna slow down your re-renders and it's gonna be visibly noticeable. So React kind of gives you an escape hatch for that called shouldComponentUpdate.

[00:06:30] And if you are going to be better at telling React to update than React itself will be, then that's when you kind of lean on shouldComponentUpdate. So, for example, maybe you can look at some id and say, okay, if just the id changed then I know I need to update.

[00:06:46] But if the id didn't change then don't bother looking at everything else. That's something you would do in shouldComponentUpdate. Another thing is what happens if you have a component that just never updates? Or should never update than you just say shouldComponentUpdate, return false. And then it will never update ever.

[00:07:08] Question?
>> Speaker 2: Okay this is a remark coming back to the using AJAX in the didMount.
>> Brian Holt: Mm-hm.
>> Speaker 2: Anton is asking, is it really better to make AJAX calls in componentDidMount rather than componentWillMount? I heard that someone from React community suggested to use timers in componentDidMountHook but AJAX calls and componentWillNotHook?

>> Brian Holt: Yeah, I mean I can see what you're getting at because you wanna kick off those AJAX calls as soon as possible. Honestly, the difference between willMount and didMount is gonna be in milliseconds, so I think you're taking the happy path by just putting it in didMount. And your code looks better, it's easier to read.

[00:07:50] If those milliseconds are precious and critical to you, then you can do some more fancy-pants stuff. But I would argue that you wouldn't do it in willMount, you would actually go even further outside of that. And maybe doing it even before React bootstraps, right? Because then you're gonna cut out a bunch of time and then do some sort of like side loading of cache.

[00:08:09] So my simple answer to that question is that's definitely an advanced use case and I would not suggest going down there unless you have to.
>> Brian Holt: Going back to shouldComponentUpdate. I recommend avoiding shouldComponentUpdate until you absolutely must use it. React is really good at what it does. It's really good at finding difs and being really fast about it, especially for shallow data.

[00:08:35] For like stuff that we've done here. Nothing we've done here should we ever put shouldComponentUpdates because as-is is fast enough. The reason why I say that is you're going to come back later to these components and you're going to update something and all of a sudden you're going to expect it to change data in a different way.

[00:08:51] And if you have a shouldComponentUpdate return false, your component's never going to update and you're going to be like why is this not updating? I'm changing the data why is it not updating? So it introduces these weird bugs especially as you come back to maintain stuff. So it's like let's React do React, right and then come back to fixing that are the bottlenecks.

[00:09:10] This is also generally good programming advice like don't introduce caching, don't introduce minimalization, all that stuff, until you absolutely have to because that stuff's hard, right? You ends up with bigger problems. Does that make sense? Something I'm not gonna show you today, but one can look at later.

[00:09:30] There's a thing called the React perf tools, which come from React. And you can actually visualize and see charts of where your application is wasting render cycles. So it has three different metrics, print inclusive, print exclusive, and print wasted. Print inclusive is going to include life cycle methods.

[00:09:52] Print exclusive is going to exclude life cycle methods. And print wasted is just going to show you where you're literally just wasting time. You're literally just running renders that are not doing anything or all that kind of stuff. This will be really telling of where you should put in shouldComponentUpdate, so definitely dig into those, especially if you have an app that's going slow.

[00:10:16] And one thing I'll definitely throw out is avoid putting your SPGs as React components. SPGs tend to get complicated really quickly, just cuz there's lots of lines and paths and shapes and all sorts of stuff like that. There's cool stuff you can do with it, right? React knows how to do SPG cuz it's just XML, right?

[00:10:35] You can do JSX, SPGs, but they tend to be slow. So if you're not doing any sort of like direct manipulation of the SVG with React, I'd say, leave them outside of React.
>> Speaker 3: Would you go hardware acceleration?
>> Brian Holt: No difference, right. The browser is still rendering in SVG the same way.

[00:10:55] So, no that's however the browser's doing it. This is just how it gets to the browser eventually.
>> Speaker 2: I'm not sure if this one got asked already. Michael is asking does onEnter still exist in React Router?
>> Brian Holt: No.
>> Brian Holt: Good question. I didn't do anything with animation so you'd have to go look yourself.

[00:11:18] I don't believe it did make it, though.
>> Brian Holt: Yeah, I think you would just lean on the typical React lifecycles of how you would normally do React animations.