[compiler] ref guards apply up to fallthrough of the test #34024

josephsavona · 2025-07-28T16:49:27Z

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.

Stack created with Sapling. Best reviewed with ReviewStack.

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.

`@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)

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] disallow ref access in state initializer, reducer/initializer #34025

Merged

[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 pr34024 branch from 963141d to 0bae1e3 Compare July 29, 2025 17:02

josephsavona force-pushed the pr34024 branch from 0bae1e3 to b383925 Compare July 29, 2025 17:05

josephsavona force-pushed the pr34024 branch from b383925 to 70148cd Compare July 29, 2025 17:47

josephsavona force-pushed the pr34024 branch from 70148cd to be41c94 Compare July 29, 2025 17:52

josephsavona merged commit 4395689 into main Jul 29, 2025
12 of 14 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] ref guards apply up to fallthrough of the test #34024

[compiler] ref guards apply up to fallthrough of the test #34024

josephsavona commented Jul 28, 2025 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

[compiler] ref guards apply up to fallthrough of the test #34024

[compiler] ref guards apply up to fallthrough of the test #34024

Conversation

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

Uh oh!

Uh oh!

Uh oh!

Uh oh!

josephsavona commented Jul 28, 2025 •

edited

Loading