Question about "calling an impure function can produce unstable results..." lint

[controversial]

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-compiler (build issue installing or using the eslint plugin)
• react-compiler-healthcheck (build issue installing or using the healthcheck script)

Link to repro

https://playground.react.dev/#N4Igzg9grgTgxgUxALhASwLYAcIwC4AEwBUYCAsghhAQL4EBmMEGBA5DAgIZx5sDcAHQB2IhAA8c+AgBMEDLlAA2hBlGG80EYQXIBPAIJYsACgCUREQQJxtYQva74AKpgQEAvCTKVqJ854AfARYCDAMuBhcGggAdMIQAO7mZkLCtCIgtEA

Repro steps

Run eslint-plugin-react-hooks with the react-compiler rule enabled

export default function MyApp() {
  const startTime = useMemo(() => performance.now());
}

The error says

Calling an impure function can produce unstable results that update unpredictably when the component happens to re-render

I’m not sure what the right way to record this type of state is now, because react-compiler also rejects anything of the form

  const [startTime, setStartTime] = useState(null);
  useEffect(() => { setStartTime(performance.now()); }, []);

for “calling setState synchronously within an effect body.”

How often does this bug happen?

Every time

What version of React are you using?

react@19.1.1

What version of React Compiler are you using?

eslint-plugin-react-hooks@0.0.0-experimental-97cdd5d3-20250710

[controversial]

Is the “correct” way with useSyncExternalStore?

  const startTime = useSyncExternalStore(
    () => () => { },
    () => performance.now(),
    () => performance.now(),
  );

that seems equivalent to the original useMemo approach, to me, except maybe it provides additional hydration safety?

In either case, I think the error message is misleading because it states the issue is that the value will be unstable between re-renders, when in fact the value is memoized + stable between re-renders

[josephsavona]

Hey @controversial, thanks for posting! This lint is correctly flagging a potential issue with your code. A common mistake we see is people calling functions like Date.now() or performance.now() during render, when the results are often not going to work as the developers intends. Memoization is strictly a performance optimization, so the fact that the code was originally memoized doesn't really impact correctness.

If you're using performance.now() it's probably because you're trying to measure performance in some way. Can you clarify what exactly you're trying to measure though? Note that with features like <Suspense /> and <Activity />, the performance.now() call may not be running when you expect. If you're trying to measure when a UI component becomes visible, for example, the most accurate approach is to use an Intersection Observer to check when the component's element enters the viewport. The fact that the component's render executed doesn't tell you that it was actually visible. But again, the right approach depends on what you're trying to do.

[controversial]

Hi @josephsavona,

In this case it's a timestamp for when the component has mounted in order to display other timestamps relative to this “start time“ - one piece of state should hold the start time, and another "current time" piece of state would be subtracted to display a relative time

What's the recommended way to record a "baseline" start time when a component first rendered, if it's not useState and it's not useEffect? Should I use useSyncExternalStore?

[josephsavona]

That makes sense. In that case, all the timing data is only used outside of render, so the recommended solution is to use refs (as the docs say: a ref is "a value that’s not needed for rendering"). Then you could set and access these values in effects.

Something like

const timingRef = useRef(null);
useEffect(() => {
  if (timingRef.current == null) {
    timingRef.current = performance.now();
  }
}, [...]);

And then maybe share timingRef via context so that other components can compare relative timing.

But again, when the component mounted often isn't actually the interesting data — a component can mount but not be visible. I would recommend considering whether "component became visible" is a more useful metric, in which an intersection observer is more appropriate (set up via an effect, or a third-party library that wraps this up for you).

[controversial]

You’re right to point out that I’m only using startTime outside of render in my case; I can use useRef.

[controversial]

useRef(performance.now()) is a react compiler error as well, though, so I don’t think that solves the actual issue here.

[josephsavona]

Yeah, that's intentional. The ref initialization can happen at arbitrary times due to things ike pre-rendering from <Activity /> or multiple renders from <Suspense />. If you want to access the time that the component is mounted, that corresponds to when useEffect() fires. Hence the snippet above:

const timingRef = useRef(null);
useEffect(() => {
  if (timingRef.current == null) {
    timingRef.current = performance.now();
  }
}, [...]);

edit: postscript - I can also see allowing useRef(performance.now()) because you are opting in to using a ref, which is already an unsafe escape hatch.

[controversial]

Note also #34045 - it’s often excessively difficult under the new react-compiler rules to initialize this type of variable in an effect in cases where it does need to be accessed during render, including

• initializing IntersectionObserver state as part of an effect, initializing window.matchMedia state as part of an effect, or similar
• initializing a state variable in an effect such as “component mounted time” or “component has mounted”