React Lifecycle, Part 2: Update Phase

Full Stack Web and Mobile Applications with React, React-Native, iOS and Android

React Lifecycle, Part 2: Update Phase

React component lifecycle update process

In part one, we looked at the initialization and creation phase of the React component lifecycle, called mounting. In this post we will dive into an integral part of what makes React so powerful, the update phase of the component lifecycle.

The way that React does its re-rendering using a virtual DOM is actually quite fascinating and is largely what makes React so powerful. This is a topic for another post, but here’s the short version: when an object in the dom is bound to a state property whose value is changed, that object is marked dirty. React then updates the virtual DOM and and uses a diffing algorithm to reconcile and update the actual DOM. Why does it do this? One word: performance. Rendering changes directly to the DOM is expensive because once a node is updated, every child in the tree has to go through the process of being laid out and re-painted again, so the larger your app gets, the slower this process becomes.  This brings us to the update phase of the lifecycle, displayed in the box on the right side of Figure 1.

React Component lifecycle diagram

Figure 1: The update methods are shown in the yellow boxes on the right


When the update process begins, React runs a batch update that loops over the components in the dirty array. If there is a pending state update that is queued, or if a call to forceUpdate() was made. All pending state changes will then be queued for update, beginning with the componentWillReceiveProps(nextProps) method.


This provides the opportunity to update the component’s state with next props. Say for example your container component holding all your stateless presentation components just received updated data. A great example might be a real-time charting component that is updated every few seconds, or someone creating a new event in a shared calendar while you have it open. When you use this, you want to start by making a comparison between this.props and nextProps to see what has changed. If the change is important, then run the necessary operation.

componentWillReceiveProps(nextProps) {
    if (this.props.match.path !== nextProps.match.path && nextProps.match.path === '/Latest_News') {
      this.forceUpdate(res => {this.initialize()});

In this code we have to check our browser path for a special use case where if it matches a specific path, we need to run a forceUpdate() that runs this.initialize() to capture new data that is then put in state.

shouldComponentUpdate(nextProps, nextState)

This method allows you to explicitly declare whether you want things to re-render. This can be used to optimize performance if you want to do a comparison and prevent re-rendering under certain circumstances that would normally cause React to trigger such a re-render. This method must return true or false. Do NOT call this.setState() here or react will freak out on you.

React Component Lifecycle: update phase

React Component Lifecycle: update phase

componentWillUpdate(nextProps, nextState)

This method is sort of pointless in my opinion. I have not found many use cases for it, if any. It is essentially the same as componentWillReceiveProps, but unlike that method, you can’t call this.setState().

componentDidUpdate(prevProps, prevState)

This occurs after the render() function and thus you have a “clean” version of the component to operate on. However, your operations should have been run in the componentWillReceiveProps method because that is where you can determine why your component is updating (by running the comparison). In componentDidUpdate, you don’t know why it was updated, and you don’t want to waste time redrawing the canvas every time it updates when you don’t know whether or not the props you’re receiving are even relevant. However, this is a good time to run any display operations such as running a filter function over the data to only show pertinent items.

Component tear-down

When the component is destroyed, there is just one place for you to do all your cleanup: componentWillUnmount(). This is where you’ll want to kill any running processes and remove your event listeners.



Leave a Reply

Your email address will not be published.