Life Cycle Methods
A React Component has a set of so called life cycle methods. They are a set of pre defined methods that are called when certain criteria are met. In the react world we use the terms “mounting” and “umounting”, it simply means mounted into to the DOM. Kind of like when you mount or unmount a disk.
There are five categories of life cycle methods: mounting, unmounting, error handling and other. All of them follow a naming convention that makes a lot of sense once you get used to it. If it contains “will” it will be called before and if it contains “did” it will be called after.
contructor(). This is technically not a react method, but rather the same method all classes has. It is what is called when an instance of the class is initiated. This is the place you will set the inital state, bind various methods and so on. I usually also fetch data in the constructor. It takes props as its only argument. </p> <p> componentWillMount(). This is the method that is called right before, rendering. It doesn’t trigger a re-render if you change state. </p> <p> render(). The render method is the only “required” method in a component. This is where you write what will be the output from the component. </p> <p> componentDidMount(). This method is called right after it is done rendering. If you don’t want to have your code for fetching data from backend in your constructor, then this is a good option. This is where I had them before I discovered class-based components. </p>
componentWillReceiveProps(nextProps) is called when your component recieve new props. It is very useful if, for example you need to change something in state, when the properties change. For example you have a “Edit Blog Post” component, the id comes by props and you need to change the state for the new post. </p> <p> shouldComponentUpdate(nextProps, nextState). This is a method called when react want to update, because state or props changed. You can use it to control if your component should update or not. It won’t update if you return false. To use this method should be a last resort, and I would make sure everything else is optimized, including using PureComponent instead of Component as a base before using this. And don’t do soemthing dumb like comparing with JSON.stringify in it… </p> <p> componentWillUpdate(nextProps, nextState) this is called right before an update. </p> <p> componentDidUpdate(prevProps, prevState) this is called right after an update. </p>
componentWillUnmount() is called right before your component is removed. Do any required cleanup etc here.
The two pairs are kind of the same, you can’t call setState or anything in any of them, because that would be a incredibly dumb infinite loop. willMount is only called before the first render, and willUpdate is called before every render after the first; and the same goes for didMount / didUpdate, the only difference is that it is called after. </p> <p> I almost never use them, but you use them if you need to do something in the DOM before or after render. Like hooking up or down some jQuery stuff for example. </p>
componentDidCatch(error, info) was a very welcomed addition to React 16. If a exception is thrown in any component in it or anywhere under it, this method is called. This means that it is much easier to display a “Something went to shit” message and to collect errors with react. The old way used to be a white screen and a error in the console. Which was terrible.
Then we have two methods left, setState and forceUpdate; I’m not going to talk more about setState, because we have covered it pretty well. forceUpdate on the other hand is a method where you can force React to re-render. </p> <p> forceUpdate is a interesting beast. And while I see that there might be a need for it, I have never had it. This is one of the areas where I’m left with “are you sure there isn’t something else that is wrong here” feeling. </p>
The life cycle methods in React are very powerful, and you can use them to do more or less anything. A good advice from someone who has made more or less any mistake in the book: don’t override the update life cycle stuff unless you have to.