[Compiler Bug]: ref initialization using `=== null` doesn't work with impure functions

[simarmol]

What kind of issue is this?

• React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
• babel-plugin-react-compiler (build issue installing or using the Babel plugin)
• eslint-plugin-react-hooks (build issue installing or using the eslint plugin)
• react-compiler-healthcheck (build issue installing or using the healthcheck script)

Link to repro

https://eslint-online-playground.netlify.app/#eNqlVM1um0AQfpXRXupExNydOmqlJGpOrZKqPQQfKAx442UX7U/iyELqQ/QJ+ySdYbENbtRLhQ1o99tvvvlmhp1wtkhxmzetwvmT24qFkE1rrIcdBIf3WCX8vKkqLDx0UFnTQCYs5oXPxGWm+aqCLrw0Gr4EizeRbHYGu0wD8L8w2nmwWMFyIJ3poNQZHQeQFcxoa14Ea1F7WC6X0O/G8wBpCodFKNZYbKA06PQ7D97KukbbU0tND12ijacmlKS4FwvQ8Y0YTfBOlgh+jUdy6QGtNdYx6JRAmxaJpt/xwWp4X8rnq5YyptB08sXYjXuf8iJFojh8sfa7pgdV5Jixr/D75y/mdmCDQsiVMi8uAYJI/xrXbu/ubx5GrkaCE1//z9Npcte5x7k2L7OzS/amL+7F2piNSwddvS2wRouDifw49MWMRC2v9tyszFA3KVPPMtGYoD2WkFO7JOO4UWmXwOOKX0+NpS48WPtDmWKD5dRctpYUPHgS35ufWwpV9v6O3YwOj+z8fsC+aenjoPijX0Vr+whDikenovyx4qOGo1CRCHRKaj8n8krWNGLHCet9/sQ278cqYi9aFWqpL0Z1GEYNt/3BEqs8KJLKEgbXK6nQLWhJnJ+n5/Pdk0tonBPv6LftMrFKIi5yE3K3H+N9hMVYUDfAVa7rkNf4uWXv+FhcJ6LcOrR/rwNg0eTf0DraWFAQRZ45rv4R4UywBX59bZEBjSmpUBMAU9xiTuZyUjugVBY07QEPwrh14tv+ydUeC5mkNzQyZ0k2czeP4k2RPJxv4WIcvq8uqa5tXmzIGKqo0VTT+LETnnKKhydZZaLE52ts+QOlC4l9gEFpJj7EuqdPQ9wTx/Z98c/NN5tmjD8Mbie6P5C2ABI=

Repro steps

See the link for playground.

Basically, the ref-in-render rule doc states that this very specific access is allowed:

Example 1:

// ✅ Lazy initialization of ref value
function Component() {
  const ref = useRef(null);

  // Initialize only once on first use
  if (ref.current === null) {
    ref.current = expensiveComputation(); // OK - lazy initialization
  }

However, if expensiveComputation is impure, it still fires.
Example 2:

  if (ref.current === null) {
    ref.current = Date.now(); // purity rule

And of course, useState(() => Date.now()) is fine. The react docs say

// It only runs once when the hook is called, so only the current date at the
//    time the hook is called is set first.

Between those three, I'd expect my second example to be valid, but it's not?

How often does this bug happen?

Every time

What version of React are you using?

19.0.1

What version of React Compiler are you using?

1.0.0

[angular-bootstrap]

I took a look at this and it seems like a docs / expectation mismatch more than a lint bug.

From the current implementation, the null-check pattern is only a special-case allowance for the refs rule:

if (ref.current == null) {
  ref.current = ...
}

But purity still applies to whatever is on the right-hand side, so Date.now() is still rejected because it’s impure during render.

So the current behavior seems to be:

refs: allow the null-guarded write pattern
purity: still reject impure initializers like Date.now()

I’m putting together a small follow-up locally to clarify this with regression coverage and docs wording, unless the intended behavior is actually to allow this case.

[simarmol]

I was kind of hoping that it was an issue with the lint rule and that the null check pattern was an exception for the purity rule in addition to the refs rule. I'd take some clarification in the docs though?

To be clear, the docs don't say the null check pattern is allowed for the purity rule! They just don't explicitly say that it isn't. It just seemed odd that the useState with impure initializer is fine, the null check ref is fine, but the null check with an impure assignment for the ref isn't when it seems like they'd be roughly equivalent.

Then again, I'm still unclear on why impure functions are fine with initializers for useState, so, eh?

[angular-bootstrap]

Yeah, I think that’s the confusing part too.

It doesn’t read like “the docs promised this should work,” but it does make these cases feel pretty similar:

• useState(() => Date.now()) is allowed
• if (ref.current == null) { ref.current = stableValue } is allowed
• if (ref.current == null) { ref.current = Date.now() } is not

From what I found, the current implementation treats those as two separate things:

• the ref null-check is an exception for the refs rule
• purity still applies to the initializer on the right-hand side

My current understanding is that useState(() => ...) is treated as a hook initializer, while the ref null-check is still just normal render code, so purity continues to apply there.

I can put together a small docs clarification and share it for review. That should help make the current behavior clearer, and then we can see what the team thinks about whether the behavior itself should change.

[matthewwalker1621-star]

Yes it is more than a bug

…

On Sat, Mar 7, 2026, 1:36 AM Harmeet Singh ***@***.***> wrote: *angular-bootstrap* left a comment (facebook/react#35973) <#35973 (comment)> Yeah, I think that’s the confusing part too. It doesn’t read like “the docs promised this should work,” but it does make these cases feel pretty similar: - useState(() => Date.now()) is allowed - if (ref.current == null) { ref.current = stableValue } is allowed - if (ref.current == null) { ref.current = Date.now() } is not From what I found, the current implementation treats those as two separate things: - the ref null-check is an exception for the refs rule - purity still applies to the initializer on the right-hand side My current understanding is that useState(() => ...) is treated as a hook initializer, while the ref null-check is still just normal render code, so purity continues to apply there. I can put together a small docs clarification and share it for review. That should help make the current behavior clearer, and then we can see what the team thinks about whether the behavior itself should change. — Reply to this email directly, view it on GitHub <#35973 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B7GHLXECLCZQV4GYKRTZQIL4PN4JXAVCNFSM6AAAAACWKATSZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMJVGE3DONBWGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>