How to fix Warning: componentWillReceiveProps has been renamed, and is not recommended for use. in React

ReactINTERMEDIATEMEDIUMUpdated Dec 8, 2025· 106 views

This warning appears in React 16.9+ when using the deprecated componentWillReceiveProps lifecycle method. React renamed it to UNSAFE_componentWillReceiveProps to signal its incompatibility with future async rendering, and recommends migrating to getDerivedStateFromProps or componentDidUpdate.

Quick fix

Fixes Warning: componentWillReceiveProps has been renamed, and is not recommended for use.

grep -r "componentWillReceiveProps" src/
  1. Identify which components are using the deprecated method
  2. Run the official React codemod for automatic renaming
  3. Migrate side effects to componentDidUpdate
  4. Replace state derivation with getDerivedStateFromProps
react — error
grep -r "componentWillReceiveProps" src/
Warning: componentWillReceiveProps has been renamed, and is not recommended for use.

What this error means

This warning indicates that your React component is using the componentWillReceiveProps lifecycle method, which was deprecated in React 16.3 and produces warnings starting in React 16.9. The method has been renamed to UNSAFE_componentWillReceiveProps to reflect that it can cause issues with React's upcoming concurrent rendering features. The componentWillReceiveProps method has historically been misused for performing side effects (like data fetching) and updating state in ways that can cause bugs. As React moves toward async rendering, these "unsafe" lifecycle methods can be called multiple times before a render actually commits, making them unreliable for operations with side effects. React strongly encourages developers to migrate away from this pattern entirely, using getDerivedStateFromProps for deriving state from props, or componentDidUpdate for side effects that need to run after prop changes.

Typical symptoms

  • Console warning appears: "Warning: componentWillReceiveProps has been renamed, and is not recommended for use"
  • Warning appears in React 16.9 or later when using the old method name
  • Warning appears for each component instance that uses componentWillReceiveProps
  • Application still functions normally despite the warning
  • Warning becomes more frequent when using StrictMode
  • Multiple warnings appear if several components use the deprecated method
  • Build tools or linters may flag the deprecated lifecycle method

Common causes

  1. Using componentWillReceiveProps without the UNSAFE_ prefix in React 16.9+
  2. Legacy code written before React 16.3 that has not been updated
  3. Third-party component libraries that still use the deprecated lifecycle
  4. Inherited code patterns from older React tutorials or examples
  5. Automatic React upgrades that preserve old lifecycle method names
  6. Copy-pasted component code from pre-16.3 React applications
  7. Using componentWillReceiveProps for side effects instead of componentDidUpdate
  8. Deriving state from props without migrating to getDerivedStateFromProps

How to fix "Warning: componentWillReceiveProps has been renamed, and is not recommended for use."

1Identify which components are using the deprecated method

Check the console warnings to see which components are triggering the warning. The warning message will typically include the component name. You can also search your codebase:

bash
grep -r "componentWillReceiveProps" src/

Or use your IDE's search feature to find all occurrences.

2Run the official React codemod for automatic renaming

React provides an automated codemod script that renames all deprecated lifecycle methods to their UNSAFE_ versions:

bash
npx react-codemod rename-unsafe-lifecycles

This will scan your project and automatically rename componentWillReceiveProps to UNSAFE_componentWillReceiveProps. This is a quick fix that suppresses the warning in non-strict mode, but is not the recommended long-term solution.

3Migrate side effects to componentDidUpdate

If your componentWillReceiveProps performs side effects like data fetching, API calls, or subscriptions, move them to componentDidUpdate:

javascript
// Before
componentWillReceiveProps(nextProps) {
  if (nextProps.userId !== this.props.userId) {
    this.fetchUserData(nextProps.userId);
  }
}

// After
componentDidUpdate(prevProps) {
  if (this.props.userId !== prevProps.userId) {
    this.fetchUserData(this.props.userId);
  }
}

Note the logic reversal: componentDidUpdate receives previous props, while componentWillReceiveProps received next props.

4Replace state derivation with getDerivedStateFromProps

If you're using componentWillReceiveProps to derive state from props, migrate to the static getDerivedStateFromProps method:

javascript
// Before
componentWillReceiveProps(nextProps) {
  if (nextProps.value !== this.props.value) {
    this.setState({ controlledValue: nextProps.value });
  }
}

// After
static getDerivedStateFromProps(props, state) {
  if (props.value !== state.controlledValue) {
    return { controlledValue: props.value };
  }
  return null;
}

Important: getDerivedStateFromProps is static, so you cannot access this. Return an object to update state, or null for no updates.

5Consider using key prop for full component reset

If you were using componentWillReceiveProps to reset component state when props change, consider making the component fully controlled or use a key prop to reset it:

javascript
// Parent component
<MyComponent key={userId} userId={userId} />

Changing the key forces React to unmount and remount the component with fresh state, eliminating the need for lifecycle-based state synchronization.

6Use memoization for expensive derived values

If you were computing values from props in componentWillReceiveProps, consider computing them during render with useMemo (if using hooks) or memoization libraries:

javascript
// Functional component with hooks
const expensiveValue = useMemo(() => {
  return computeExpensiveValue(props.data);
}, [props.data]);

For class components, compute during render and cache in instance variables if needed.

7Update third-party dependencies

If warnings come from third-party libraries, check for updated versions:

bash
npm outdated
npm update react-select react-dates

Many popular libraries have released updates that eliminate these warnings. Check the library's changelog or GitHub issues for migration guidance.

8Test thoroughly after migration

After refactoring, verify that your components behave correctly:

bash
npm test
npm run build

Pay special attention to:
- Components that derive state from props
- Side effects triggered by prop changes
- Performance-sensitive components
- Edge cases where props change rapidly

Advanced notes

The UNSAFE_ prefix doesn't mean the methods are inherently buggy or insecure - it means they are unsafe to use with React's upcoming concurrent rendering mode. In concurrent mode, React may call these methods multiple times before committing a render, or may call them without committing at all. This makes them unreliable for side effects.

If you're using StrictMode in development, React intentionally double-invokes certain lifecycle methods to help catch bugs. This can make the warnings more prominent.

For React 17+, the old lifecycle names (without UNSAFE_) will stop working entirely. The UNSAFE_ variants will continue to work but are not recommended for new code.

When migrating to getDerivedStateFromProps, be aware of a common anti-pattern: blindly copying props to state on every render. React's official blog post "You Probably Don't Need Derived State" explains why this is usually a code smell and offers better alternatives like fully controlled components or components with key-based reset.

For complex state derivation logic, consider whether you actually need to derive state at all. Often, computing values directly during render (potentially memoized) is simpler and less error-prone than maintaining synchronized derived state.

Frequently asked questions

What does "Warning: componentWillReceiveProps has been renamed, and is not recomm" mean?
9. The method has been renamed to UNSAFE_componentWillReceiveProps to reflect that it can cause issues with React's upcoming concurrent rendering features. The componentWillReceiveProps method has historically been misused for performing side effects (like data fetching) and updating state in ways that can cause bugs.
How do I fix "Warning: componentWillReceiveProps has been renamed, and is not recomm"?
This warning appears in React 16.9+ when using the deprecated componentWillReceiveProps lifecycle method. React renamed it to UNSAFE_componentWillReceiveProps to signal its incompatibility with future async rendering, and recommends migrating to getDerivedStateFromProps or componentDidUpdate.
What causes "Warning: componentWillReceiveProps has been renamed, and is not recomm"?
Using componentWillReceiveProps without the UNSAFE_ prefix in React 16.9+ Legacy code written before React 16.3 that has not been updated Third-party component libraries that still use the deprecated lifecycle
Is the "Warning: componentWillReceiveProps has been renamed, and is not recomm" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading