[compiler] disallow ref access in state initializer, reducer/initializer #34025

josephsavona · 2025-07-28T17:28:01Z

Per title, disallow ref access in useState() initializer function, useReducer() reducer, and useReducer() init function.

Stack created with Sapling. Best reviewed with ReviewStack.

josephsavona · 2025-07-28T17:33:59Z

Closes #31418

We added the `@enableTreatRefLikeIdentifiersAsRefs` feature a while back but never enabled it. Since then we've continued to see examples that motivate this mode, so here we're fixing it up to prepare to enable by default. It now works as follows: * If we find a property load or property store where both a) the object's name is ref-like (`ref` or `-Ref`) and b) the property is `current`, we infer the object itself as a ref and the value of the property as a ref value. Originally the feature only detected property loads, not stores. * Inferred refs are not considered stable (this is a change from the original implementation). The only way to get a stable ref is by calling `useRef()`. We've seen issues with assuming refs are stable. With this change, cases like the following now correctly error: ```js function Foo(props) { const fooRef = props.fooRef; fooRef.current = true; ^^^^^^^^^^^^^^ cannot modify ref in render } ``` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/34000). * #34027 * #34026 * #34025 * #34024 * #34005 * #34006 * #34004 * #34003 * __->__ #34000

Improves the error message for ValidateNoRefAccessInRender, using the new diagnostic type as well as providing a longer but succinct summary of what refs are for and why they're unsafe to access in render. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/34003). * #34027 * #34026 * #34025 * #34024 * #34005 * #34006 * #34004 * __->__ #34003

We added the `@enableTreatRefLikeIdentifiersAsRefs` feature a while back but never enabled it. Since then we've continued to see examples that motivate this mode, so here we're fixing it up to prepare to enable by default. It now works as follows: * If we find a property load or property store where both a) the object's name is ref-like (`ref` or `-Ref`) and b) the property is `current`, we infer the object itself as a ref and the value of the property as a ref value. Originally the feature only detected property loads, not stores. * Inferred refs are not considered stable (this is a change from the original implementation). The only way to get a stable ref is by calling `useRef()`. We've seen issues with assuming refs are stable. With this change, cases like the following now correctly error: ```js function Foo(props) { const fooRef = props.fooRef; fooRef.current = true; ^^^^^^^^^^^^^^ cannot modify ref in render } ``` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/34000). * #34027 * #34026 * #34025 * #34024 * #34005 * #34006 * #34004 * #34003 * __->__ #34000 DiffTrain build for [85bbe39](85bbe39)

…p) (#34004) Two related changes: * ValidateNoRefAccessInRender now allows the mergeRefs pattern, ie a function that aggregates multiple refs into a new ref. This is the main case where we have seen false positive no-ref-in-render errors. * Behind `@enableTreatRefLikeIdentifiersAsRefs`, we infer values passed as the `ref` prop to some JSX as refs. The second change is potentially helpful for situations such as ```js function Component({ref: parentRef}) { const childRef = useRef(null); const mergedRef = mergeRefs(parentRef, childRef); useEffect(() => { // generally accesses childRef, not mergedRef }, []); return <Foo ref={mergedRef} />; } ``` Ie where you create a merged ref but don't access its `.current` property. Without inferring `ref` props as refs, we'd fail to allow this merge refs case. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/34004). * #34027 * #34026 * #34025 * #34024 * #34005 * #34006 * __->__ #34004

We infer render helpers as functions whose result is immediately interpolated into jsx. This is a very conservative approximation, to help with common cases like `<Foo>{props.renderItem(ref)}</Foo>`. The idea is similar to hooks that it's ultimately on the developer to catch ref-in-render validations (and the runtime detects them too), so we can be a bit more relaxed since there are valid reasons to use this pattern. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/34006). * #34027 * #34026 * #34025 * #34024 * #34005 * __->__ #34006 * #34004

Improves the error message for ValidateNoRefAccessInRender, using the new diagnostic type as well as providing a longer but succinct summary of what refs are for and why they're unsafe to access in render. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/34003). * #34027 * #34026 * #34025 * #34024 * #34005 * #34006 * #34004 * __->__ #34003 DiffTrain build for [79dc706](79dc706)

…p) (#34004) Two related changes: * ValidateNoRefAccessInRender now allows the mergeRefs pattern, ie a function that aggregates multiple refs into a new ref. This is the main case where we have seen false positive no-ref-in-render errors. * Behind `@enableTreatRefLikeIdentifiersAsRefs`, we infer values passed as the `ref` prop to some JSX as refs. The second change is potentially helpful for situations such as ```js function Component({ref: parentRef}) { const childRef = useRef(null); const mergedRef = mergeRefs(parentRef, childRef); useEffect(() => { // generally accesses childRef, not mergedRef }, []); return <Foo ref={mergedRef} />; } ``` Ie where you create a merged ref but don't access its `.current` property. Without inferring `ref` props as refs, we'd fail to allow this merge refs case. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/34004). * #34027 * #34026 * #34025 * #34024 * #34005 * #34006 * __->__ #34004 DiffTrain build for [1d7e942](1d7e942)

`@enableTreatRefLikeIdentifiersAsRefs` is now on by default. I made one small fix to the render helper logic as part of this, uncovered by including more tests. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/34005). * #34027 * #34026 * #34025 * #34024 * __->__ #34005

Fixes #30782 When developers do an `if (ref.current == null)` guard for lazy ref initialization, the "safe" blocks should extend up to the if's fallthrough. Previously we only allowed writing to the ref in the if consequent, but this meant that you couldn't use a ternary, logical, etc in the if body. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/34024). * #34027 * #34026 * #34025 * __->__ #34024

Per title, disallow ref access in `useState()` initializer function, `useReducer()` reducer, and `useReducer()` init function.

`@enableTreatRefLikeIdentifiersAsRefs` is now on by default. I made one small fix to the render helper logic as part of this, uncovered by including more tests. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/34005). * #34027 * #34026 * #34025 * #34024 * __->__ #34005 DiffTrain build for [6891dcb](6891dcb)

…zer (#34025) Per title, disallow ref access in `useState()` initializer function, `useReducer()` reducer, and `useReducer()` init function. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/facebook/react/pull/34025). * #34027 * #34026 * __->__ #34025 DiffTrain build for [c2326b1](c2326b1)

facebook-github-bot added the CLA Signed label Jul 28, 2025

github-actions bot added the React Core Team Opened by a member of the React Core Team label Jul 28, 2025

This was referenced Jul 28, 2025

[Compiler Bug]: Does not check for ref access in useState initial value function #31418

Closed

[compiler] Allow assigning ref-accessing functions to objects if not mutated #34026

Merged

[compiler] Detect known incompatible libraries #34027

Open

poteto approved these changes Jul 29, 2025

View reviewed changes

josephsavona force-pushed the pr34025 branch from e6eddf6 to 017158d Compare July 29, 2025 17:02

josephsavona force-pushed the pr34025 branch from 017158d to 966897a Compare July 29, 2025 17:05

josephsavona force-pushed the pr34025 branch from 966897a to 32ddb19 Compare July 29, 2025 17:47

josephsavona force-pushed the pr34025 branch from 32ddb19 to ac26880 Compare July 29, 2025 17:52

[compiler] disallow ref access in state initializer, reducer/initializer

b562526

Per title, disallow ref access in `useState()` initializer function, `useReducer()` reducer, and `useReducer()` init function.

josephsavona force-pushed the pr34025 branch from ac26880 to b562526 Compare July 29, 2025 17:55

josephsavona merged commit c2326b1 into main Jul 29, 2025
12 of 15 checks passed

nextjs-bot mentioned this pull request Jul 30, 2025

Upgrade React from 9be531cd-20250729 to 9784cb37-20250730 vercel/next.js#82207

Merged

austinderek mentioned this pull request Jul 30, 2025

Upgrade React from 9be531cd-20250729 to 9784cb37-20250730 austinderek/next.js#59

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[compiler] disallow ref access in state initializer, reducer/initializer #34025

[compiler] disallow ref access in state initializer, reducer/initializer #34025

josephsavona commented Jul 28, 2025 •

edited

Loading

Uh oh!

josephsavona commented Jul 28, 2025

Uh oh!

Uh oh!

Uh oh!

[compiler] disallow ref access in state initializer, reducer/initializer #34025

[compiler] disallow ref access in state initializer, reducer/initializer #34025

Conversation

josephsavona commented Jul 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

josephsavona commented Jul 28, 2025

Uh oh!

Uh oh!

Uh oh!

josephsavona commented Jul 28, 2025 •

edited

Loading