You are reading an older React class component and find a method named UNSAFE_componentWillReceiveProps. What does the UNSAFE_ prefix mean, and what should the code use instead?

## What the prefix actually communicates Seeing `UNSAFE_` in a code review makes people think of a security escape hatch, like `dangerouslySetInnerHTML`. It is not that. React renamed three lifecycle methods with a deliberately alarming prefix so that every call site is self-documenting: *this method belongs to an execution model React has moved away from*. Nothing about it is exploitable; it is unsafe in the sense of "you cannot rely on when or how often this runs". The three are: - `UNSAFE_componentWillMount` - `UNSAFE_componentWillReceiveProps` - `UNSAFE_componentWillUpdate` ## Why they became unsafe React splits work into a **render phase** — calling your component to figure out what the UI should look like — and a **commit phase**, where it applies the result to the DOM. The render phase must be safe to interrupt: React may pause partway, drop the work entirely because something more urgent arrived, and start over from the top. All three `componentWill*` methods run in the render phase. The consequences are concrete: - Code in them can run **more than once** for a single visible update. - Code in them can run for a render that is **never committed**, so its paired teardown never happens. - `componentWillMount` runs during server rendering, where `componentWillUnmount` does not exist. A subscription or timer started there leaks on every server request. ```jsx // The classic leak: started in the render phase, never torn down. UNSAFE_componentWillMount() { this.subscription = store.subscribe(this.handleChange); } ``` `componentWillReceiveProps` had a second problem beyond timing: it encouraged copying props into state on every incoming prop, which duplicates a source of truth and produces components that show stale values after an update. ## The replacements | Legacy method | What to use | | --- | --- | | UNSAFE_componentWillMount | the constructor for initial state; componentDidMount for side effects and subscriptions | | UNSAFE_componentWillReceiveProps | static getDerivedStateFromProps, or better, derive the value during render instead of storing it | | UNSAFE_componentWillUpdate | getSnapshotBeforeUpdate to read the DOM just before mutation, with componentDidUpdate to act on it | All of these are commit-phase or pure, so they run exactly once per committed update. ## Where it stands in React 19 The prefixed aliases arrived in React 16.3, and React 16.9 started warning when the old unprefixed names were used. Class components and the `UNSAFE_` aliases still work in React 19 — this is not code that breaks on upgrade — but they receive no investment, they read as a warning sign in every review, and nothing new in React is designed with them in mind. ## What to say In an interview the good answer is three sentences: the prefix marks render-phase lifecycles that React can run repeatedly or discard; that makes them wrong for side effects and it is why `componentWillMount` leaks on the server; and the fix is to move the work to the constructor, `componentDidMount`, `getDerivedStateFromProps` or `getSnapshotBeforeUpdate` depending on what the code was trying to do. Then add the practical note: finding one is not an emergency, but it is a strong signal that the component is due for migration.