React Component lifecycle methods, part II

Welcome to part II of React Component lifecycle methods! Here, we are going over the many React built-in methods and tools that are called during the lifecycle of a React component. You can read part I here.

For this blog, I’m going to focus on the componentWillReceiveProps, shouldComponentUpdate, and componentWillUpdate functions.

The above is the life-cycle of a React component, from inception (pre-mounting) to death (unmounting).

componentWillReceiveProps(nextProps)

What’s great about React lifecycle components is that they are names really well. As you can guess from its name, this function will be called when a stream of new props arrive from the parent component. For example, maybe some data was finally loaded by a parent component’s componentDidMount, and is now being passed down to all of its children.

Before our component does anything with the new props, componentWillReceiveProps is called with the next props as the argument (very important!). This function will not work without passing in nextProps as an argument, so always remember that.

componentWillReceiveProps(nextProps){
   if(this.props.id !== nextProps.id){
      this.setState({
         id: nextProps.id,
         pastId: this.props.id
      })
   }
}

If you notice, within componentWillReceiveProps we have access to both the new props (nextProps) and the current props (this.props). This can be really fun, but also confusing. Also note that componentWillReceiveProps is also not called on the initial render. If you think about it, this makes a lot of sense, though. On initial render, the component is receiving props but there are no previous props to compare it to. Thus, React doesn’t call this function then.

Another thing to keep in mind is that sometimes componentWillReceiveProps is called when nothing has changes, merely just because React wants to check in with the component. This often happens when a parent component is re-rendered with no change to this component’s props.

To handle this, here is some tips:

1. within componentWillReceiveProps, check which props will change.
2. If the props changed, act on it.

shouldComponentUpdate(nextProps, nextState)

Okay, so we for sure have new props. Typical React lifecycle dictates that when a component receives new props or state is updated, it should itself update and re-render.

But… with shouldComponentUpdate our component is asking permission first. How polite! React does this with the shouldComponentUpdate method, called with nextProps and nextState as arguments.

shouldComponentUpdate should always return a boolean. This makes sense, because in the real world when you ask permission you always get a yes/no answer. With a boolean, the answer to the question “should I re-render?” should always be true or false.

As you can guess, shouldComponentUpdate is a fantastic place to improve performance. In this way, you can remove from your app any unnecessary renders and other lifecycle method calls. Using shouldComponentUpdate, you can decide if and when your component updates. This can be a powerful tool! However, keep in mind that this can cause major problems if you forget about it later down the road, because using this method causes your component not to update normally.

ShouldComponentUpdate allows us to say: only update if the props you care about change.

ShouldComponentUpdate(nextProps, nextState){
   return (
      (this.props.id !== nextProps.id) || 
      (this.state.input !== nextState.input)
   )
}

componentWillUpdate

At this point, our component has committed to updating. At this point, our component is asking “Want me to do anything else before I re-render?” If this seems annoying, that’s because it is. This is because componentWillUpdate is functionally the same as componentWillReceiveProps (see above).

In cases where shouldComponentUpdate is implemented, this function can be used instead of componentWillReceiveProps. But, in my opinion, I would still with componentWillReceiveProps whenever possible. It’s a lot cleaner, and the naming of the components make it less confusing and easier to debug. Most developers feel the same way as well… so just don’t do it.

We’ve reached the end of this portion of discussing React lifecycle methods! We’ve covered all of the built in React methods that handle what happens when a component’s props change or a re-render is otherwise starting to be triggered. I hope you’re starting to get the hang of the whole component lifecycle as a whole. See you next time!