# React: Initialize State from Props Correctly

> Avoid the initializing-state-from-props anti-pattern in React class components, and see the modern approach for syncing state with changing props

**URL:** https://sentry.io/answers/using-props-to-initialize-state/

---

## The Problem

Where the props are used to set the initial state of the Component is a general anti-pattern of React. This implies that the state of the component is tied to the props of the component. The issue with doing this is that the constructor is only ever called once in the life cycle of the component. Since the props can change many times during that lifecycle, that implication is broken.

```jsx
class MyComponent extends Component {
    constructor(props) {
        super(props)
        this.state = {
            name: props.name,
        }
    }
}
```

## The Solution

This is an anti-pattern that should be avoided. Note that `componentWillReceiveProps` was deprecated in React 16.3 and removed in React 17, so it's no longer a working fix — only the legacy `UNSAFE_componentWillReceiveProps` name still exists, kept for old code that hasn't migrated yet.

If you're maintaining a class component and truly need to derive part of its state from changing props, use [`static getDerivedStateFromProps`](https://react.dev/reference/react/Component#static-getderivedstatefromprops) instead. It runs before every render, so you need to store the previous prop value in state to detect an actual change:

```jsx
class MyComponent extends Component {
    constructor(props) {
        super(props)
        this.state = {
            name: props.name,
            prevName: props.name,
        }
    }

    static getDerivedStateFromProps(props, state) {
        if (props.name !== state.prevName) {
            return {
                name: props.name,
                prevName: props.name,
            }
        }
        return null
    }
}
```

React's own documentation actively discourages this pattern, though. If your goal is to reset a component's state whenever a prop changes, the recommended fix is to make the component fully controlled (no local state — pass `name` and an `onChange` handler as props) or fully uncontrolled with a `key`, which tells React to unmount and remount the component with fresh state:

```jsx
<MyComponent key={props.userId} name={props.name} />
```

For function components, which are the current default in React, there's no direct equivalent of `getDerivedStateFromProps`. The same `key`-based reset applies, or you can compute the derived value directly during render instead of storing it in state at all.

The constructor-only pattern shown in "The Problem" section above remains valid if the props are explicitly meant to initialize the state once, and after that the component manages its own state.

### Further Reading

If you're looking to get a deeper understanding of how React application monitoring works, take a look at the following articles:

- [Debug tough front end errors by giving Sentry more clues](https://blog.sentry.io/debug-tough-front-end-errors-sentry-clues/)
- [See how Aumni keeps errors out of userland](https://sentry.io/customers/aumni/)
- [Getting started with the React SDK (docs)](https://docs.sentry.io/platforms/javascript/guides/react)

---

*Source: [sentry.io/answers/using-props-to-initialize-state/](https://sentry.io/answers/using-props-to-initialize-state/)*