componentWillReceiveProps vs. componentDidUpdate In React: A Comparison

What happens when a React component gets new props? Should it update its state or call another method?

React provides lifecycle methods to manage these updates, but not all methods work the same way. Some help improve performance, while others can cause issues like unnecessary re-renders or infinite loops.

Before React 16.3, developers often used componentWillReceiveProps to track prop changes and update state. However, this method had some problems, leading React to introduce componentDidUpdate as a better way to handle updates.

So, when comparing componentWillReceiveProps vs componentDidUpdate, which one should be used?

Let’s break it down.

Understanding the Component Lifecycle

Every react component follows a defined cycle from its initial mount to when it gets removed from the DOM. This cycle consists of different lifecycle methods, which are triggered at specific stages.

For example, when a component is first created, the initial render takes place using the render method. At this point, React sets the initial state and loads the component's props. Once mounted, the react component can respond to prop changes or updates to component state using methods like componentDidUpdate.

When props change, the component instance must decide whether it needs to re-render or update its dom nodes. Failing to handle prop changes correctly can lead to performance issues, unnecessary re-renders, or even an infinite loop if state values are updated without proper conditions.

componentWillReceiveProps: What It Does

Definition and Purpose

In React, componentWillReceiveProps was a lifecycle method used to detect prop changes before the render method was executed. It allowed a component instance to update its component state based on new props received from a parent component.

How componentWillReceiveProps Works

This method was invoked when a react component was about to receive new props but before the re-render occurred. Developers used it to compare previous props with new props and update the component's state accordingly.

1class ExampleComponent extends React.Component {
2  constructor(props) {
3    super(props);
4    this.state = {
5      data: props.initialData, // Setting initial state from props
6    };
7  }
8
9  componentWillReceiveProps(nextProps) {
10    if (nextProps.initialData !== this.props.initialData) {
11      // Updating state when prop changes
12      this.setState({ data: nextProps.initialData });
13    }
14  }
15
16  render() {
17    return <div>Data: {this.state.data}</div>;
18  }
19}

​

When This Method is Called

componentWillReceiveProps is invoked immediately before a react component receives new props from its parent component. It does not run on the initial mount, meaning it is only triggered when the component props change after the first initial render.

Common Use Cases

Handling Prop Changes Before Render

A common use case for componentWillReceiveProps was processing prop changes before the render method executed. This was especially useful when the component's state depended on new props.

For example, consider a child component that displays a filtered list based on new props received from a parent component:

1class FilteredList extends React.Component {
2  constructor(props) {
3    super(props);
4    this.state = {
5      filteredItems: props.items,
6    };
7  }
8
9  componentWillReceiveProps(nextProps) {
10    if (nextProps.items !== this.props.items) {
11      this.setState({ filteredItems: nextProps.items.filter(item => item.active) });
12    }
13  }
14
15  render() {
16    return (
17      <ul>
18        {this.state.filteredItems.map(item => (
19          <li key={item.id}>{item.name}</li>
20        ))}
21      </ul>
22    );
23  }
24}

​

Comparing New Props with Previous Props

Developers often used componentWillReceiveProps to check if new props were different from previous props before updating component state. This helped prevent unnecessary re-renders and performance bottlenecks.

1componentWillReceiveProps(nextProps) {
2  if (nextProps.someValue !== this.props.someValue) {
3    // Only update state if the value has actually changed
4    this.setState({ someStateValue: nextProps.someValue });
5  }
6}

​

Why it’s Deprecated

React deprecated componentWillReceiveProps in version 16.3 because it led to issues with incorrect component updates and made state management harder to track.

Issues with Incorrect State Updates

1. Unnecessary State Updates

   • Developers often misused componentWillReceiveProps by setting state every time new props were received, causing unintended re-renders.

2. Infinite Loops

   • If setState was called unconditionally, it could cause an infinite loop where a react component kept updating and re-rendering itself.

3. Data Fetching Issues

   • When using componentWillReceiveProps for data fetching, multiple API calls could be triggered unnecessarily when props change, leading to performance problems.

Alternative Approaches in Modern React

Since React 16.3, the recommended approach is to use either componentDidUpdate or pure functions like getDerivedStateFromProps.

Using componentDidUpdate Instead

Instead of componentWillReceiveProps, you should use componentDidUpdate, which ensures that new props or state changes are handled safely after a re-render:

1class ExampleComponent extends React.Component {
2  constructor(props) {
3    super(props);
4    this.state = { data: props.initialData };
5  }
6
7  componentDidUpdate(prevProps) {
8    if (prevProps.initialData !== this.props.initialData) {
9      this.setState({ data: this.props.initialData });
10    }
11  }
12
13  render() {
14    return <div>Data: {this.state.data}</div>;
15  }
16}

​

Using getDerivedStateFromProps (Static Method)

React also introduced getDerivedStateFromProps as a static method that replaces componentWillReceiveProps. Unlike componentDidUpdate, this method does not have access to this, making it useful for extracting pure functions when updating state from props change:

1class ExampleComponent extends React.Component {
2  constructor(props) {
3    super(props);
4    this.state = { data: props.initialData };
5  }
6
7  static getDerivedStateFromProps(nextProps, prevState) {
8    if (nextProps.initialData !== prevState.data) {
9      return { data: nextProps.initialData };
10    }
11    return null;
12  }
13
14  render() {
15    return <div>Data: {this.state.data}</div>;
16  }
17}

​

componentDidUpdate: The Modern Alternative

How It Works

componentDidUpdate is a lifecycle method in React that runs after a React component has re-rendered due to props change or component state updates. Unlike componentWillReceiveProps, which runs before the render method, componentDidUpdate is invoked immediately after the update is reflected in the DOM.

When componentDidUpdate Is Triggered

This method executes after every component update caused by either new props or a change in component's state. It is commonly used for performing side effects such as:

• Fetching data when a prop changes

• Updating the DOM nodes based on state values

• Synchronizing component state with new props

Example: Fetching Data on Prop Change

1class DataFetcher extends React.Component {
2  constructor(props) {
3    super(props);
4    this.state = { data: null };
5  }
6
7  componentDidUpdate(prevProps) {
8    if (prevProps.userId !== this.props.userId) {
9      // Fetch data only when userId prop changes
10      fetch(`https://api.example.com/user/${this.props.userId}`)
11        .then(response => response.json())
12        .then(data => this.setState({ data }));
13    }
14  }
15
16  render() {
17    return <div>{this.state.data ? JSON.stringify(this.state.data) : "Loading..."}</div>;
18  }
19}

​

Here, the API call is only triggered when userId in new props differs from previous props, preventing unnecessary data fetching.

Key Differences from componentWillReceiveProps

Feature	componentWillReceiveProps	componentDidUpdate
Timing	Before the render method	After the component re-renders
Access to DOM	No	Yes (can interact with dom nodes)
Can Trigger Side Effects?	Not recommended	Yes, safe for data fetching and DOM updates
Risk of Infinite Loops	High	Low (if correctly managed)
Deprecated?	Yes (React 16.3)	No (Preferred method)

Since componentDidUpdate runs after rendering, it provides a safer and more predictable way to handle prop changes and updates.

Best Practices

Checking for Prop Changes Before Updating State

Unlike componentWillReceiveProps, you must compare new props with previous props inside componentDidUpdate to prevent unwanted re-renders. Updating component state unconditionally inside this method can cause an infinite loop.

Incorrect Usage (Causes Infinite Loop)

1componentDidUpdate() {
2  // Unconditional setState inside componentDidUpdate - BAD PRACTICE
3  this.setState({ count: this.props.count });
4}

​

Here, setState will keep updating the component state indefinitely because componentDidUpdate gets called after every re-render.

Correct Usage (Only Update When Props Change)

1componentDidUpdate(prevProps) {
2  if (prevProps.count !== this.props.count) {
3    this.setState({ count: this.props.count });
4  }
5}

​

By comparing previous props with new props, we ensure that state values only update when necessary, avoiding unnecessary component updates.

Avoiding Unnecessary Re-Renders

To optimize performance, avoid excessive re-renders by:

1. Using Pure Functions: Move logic that doesn’t depend on the component instance outside of it.

2. Extracting Pure Functions: Handle data transformations in separate utility functions.

3. Using Memoization: Cache computed values with React.memo or useMemo in functional components.

4. Optimizing State Updates: Only update the component state when props change.

Example: Extracting a Pure Function

1const processData = (data) => {
2  return data.filter(item => item.active);
3};
4
5class OptimizedComponent extends React.Component {
6  componentDidUpdate(prevProps) {
7    if (prevProps.data !== this.props.data) {
8      const filteredData = processData(this.props.data);
9      this.setState({ processedData: filteredData });
10    }
11  }
12
13  render() {
14    return <div>Processed Data: {JSON.stringify(this.state.processedData)}</div>;
15  }
16}

​

By extracting pure functions, we reduce the complexity of componentDidUpdate, making the code cleaner and preventing redundant component updates.

Comparing componentWillReceiveProps and componentDidUpdate

Key Differences

Both componentWillReceiveProps and componentDidUpdate are lifecycle methods that handle prop changes in a react component, but they function differently in terms of timing, behavior, and best practices.

Timing of Execution in the Component Lifecycle

Feature	componentWillReceiveProps (Deprecated)	componentDidUpdate (Recommended)
When it runs	Before the render method when new props are received	After the component re-renders
Has access to updated DOM?	No	Yes (Can interact with DOM nodes)
Can trigger side effects?	Not recommended	Yes, safe for data fetching and UI updates
Access to previous state?	No	Yes
Risk of infinite loops?	High (if misused)	Lower (if properly handled)
Deprecated?	Yes	No

componentWillReceiveProps was executed before the render method, meaning it could modify the component's state before rendering the new UI. However, this often led to unnecessary re-renders, incorrect state values, and even infinite loops if setState was not handled properly.

On the other hand, componentDidUpdate runs after the re-render, meaning that any state updates triggered within it will cause another component update, but only if properly managed using previous props comparisons.

Handling Asynchronous Operations

One major problem with componentWillReceiveProps was handling asynchronous operations, such as data fetching. Since this method was called before the component updated, API calls could be triggered multiple times if prop changes happened frequently.

Example: API Call in componentWillReceiveProps (Incorrect)

1componentWillReceiveProps(nextProps) {
2  fetch(`https://api.example.com/data/${nextProps.id}`)
3    .then(response => response.json())
4    .then(data => this.setState({ data }));
5}

​

This could lead to race conditions where older API calls resolve after newer ones, causing outdated data to be displayed.

Correct Approach: API Call in componentDidUpdate

Using componentDidUpdate, we can check if new props require fetching fresh data, ensuring data fetching happens only when necessary.

1componentDidUpdate(prevProps) {
2  if (prevProps.id !== this.props.id) {
3    fetch(`https://api.example.com/data/${this.props.id}`)
4      .then(response => response.json())
5      .then(data => this.setState({ data }));
6  }
7}

​

This approach prevents unnecessary API calls, improving performance and reliability.

When to Use Each

Cases Where componentDidUpdate Is Preferred

Since componentWillReceiveProps is deprecated, componentDidUpdate should be used in the following scenarios:

1. Handling Prop Changes Correctly

   • If a child component depends on new props from a parent component, use componentDidUpdate to compare previous props and update component state.

2. Asynchronous Data Fetching

   • If fetching data based on prop changes, always use componentDidUpdate to ensure requests only happen when necessary.

3. Interacting with DOM Nodes

   • Since componentDidUpdate runs after the DOM updates, it can be used to manipulate DOM nodes based on the most recently rendered output.

Example: Scroll Position Reset on Prop Change

1componentDidUpdate(prevProps) {
2  if (prevProps.articleId !== this.props.articleId) {
3    window.scrollTo(0, 0); // Reset scroll position when article changes
4  }
5}

​

This ensures that when switching between articles, the current scroll position resets to the top, improving the user experience.

Transitioning from componentWillReceiveProps

If you're migrating a react component that uses componentWillReceiveProps, follow these steps:

1. Convert componentWillReceiveProps Logic to componentDidUpdate

Find cases where componentWillReceiveProps updates state and move them to componentDidUpdate, ensuring that previous props are checked before calling setState.

Before (Deprecated Approach)

1componentWillReceiveProps(nextProps) {
2  if (nextProps.userId !== this.props.userId) {
3    this.setState({ userData: nextProps.userData });
4  }
5}

​

After (Modern Approach with componentDidUpdate)

1componentDidUpdate(prevProps) {
2  if (prevProps.userId !== this.props.userId) {
3    this.setState({ userData: this.props.userData });
4  }
5}

​

2. Use getDerivedStateFromProps for Derived State (If Needed)

If the component's state values must be derived from component props, use getDerivedStateFromProps instead.

Before (Deprecated Approach in componentWillReceiveProps)

1componentWillReceiveProps(nextProps) {
2  if (nextProps.value !== this.props.value) {
3    this.setState({ computedValue: nextProps.value * 2 });
4  }
5}

​

After (Using getDerivedStateFromProps)

1static getDerivedStateFromProps(nextProps, prevState) {
2  if (nextProps.value !== prevState.computedValue / 2) {
3    return { computedValue: nextProps.value * 2 };
4  }
5  return null;
6}

​

3. Use Hooks in Functional Components

If transitioning from class-based components to functional components, use the useEffect hook to handle props change.

Before (Class Component with componentDidUpdate)

1componentDidUpdate(prevProps) {
2  if (prevProps.userId !== this.props.userId) {
3    fetchUserData(this.props.userId);
4  }
5}

​

After (Functional Component with useEffect)

1useEffect(() => {
2  fetchUserData(userId);
3}, [userId]); // Runs when userId changes

​

Wrapping Up: Writing Better React Code

React’s lifecycle methods help manage component updates, but using outdated ones like componentWillReceiveProps can cause problems. These include infinite loops, incorrect state values, and performance issues. A better approach is componentDidUpdate, which offers more control over re-renders, prop changes, and data fetching.

To keep React code clean and maintainable:

✅ Always compare previous props with new ones before updating state in componentDidUpdate.

✅ Use getDerivedStateFromProps only when state needs to be set from props.

✅ Switch to functional components and use useEffect for handling updates.

Following these practices helps build reliable, easy-to-maintain React components. Stay curious, keep experimenting, and explore modern React features to improve coding skills.

Short on time? Speed things up with DhiWise!

Tired of manually designing screens, coding on weekends, and technical debt? Let DhiWise handle it for you!

You can build an e-commerce store, healthcare app, portfolio, blogging website, social media or admin panel right away. Use our library of 40+ pre-built free templates to create your first application using DhiWise.