Bug: Derived value does not update in StrictMode

[amanmahajan7]

React version:
16.12.0

Steps To Reproduce

1. Enter a valid number in the textbox that uses strict mode. Notice the value changes in the textbox that does not use strict mode
2. Enter a valid number in the textbox that does not use strict mode. Notice the value does not change in the textbox that uses strict mode

Link to code example:
https://codesandbox.io/s/elated-mendeleev-1m5tm

The current behavior

Derived value does not update in strict mode

The expected behavior

Derived value should update in strict mode

[nstepien]

FWIW it works fine with the production build of react-dom, change the import in codesandbox to test it:

import ReactDOM from "react-dom/cjs/react-dom.production.min";

[bvaughn]

When StrictMode triggers different behavior, it's usually a sign of a side effect or an unsafe pattern that maybe just happens to work in most cases.

What went wrong here?

StrictMode intentionally tests for this by double-invoking render methods. This means that, in DEV mode, React will render a component once- throw away any state updates- and then render again. (Regardless of how many times a component is rendered, the observable behavior should be the same unless there are side effects.)

In this particular case, mutating a ref during render is the side effect. The way this plays out in practice is like so:

1. "loose" input changes e.g. 1 -> 2
2. "strict" input renders for the first time
   1. It changes prevValue ref from 1 -> 2 (side effect) and also updates state setInternalValue("")
   2. It immediately re-renders with the newer state value (internalValue 1 -> 2)
3. React resets component state (including the update setInternalValue("")) in preparation for the second render. (Remember, StrictMode renders twice.)
4. "strict" input renders for the second time
   1. Since the ref was mutated during the first render, it's already the same as the "new" prop so the code you expect to update the internalValue state doesn't get called.

How can you fix it?

The "quick fix" here would be to get rid of the render-phase side effect by moving your ref update to an effect:

if (prevValue.current !== value && internalValue !== "") {
  setInternalValue("");
}

useEffect(() => {
  // It's safe to update your prev-value ref here
  prevValue.current = value;
});

However, this Code Sandbox also looks like one of the derived state anti-patterns described in a blog post a while back. Maybe worth re-considering the higher level approach being used here and possibly going with a fully-controlled component instead?

Why does this matter?

It might not be obvious why this matters. After all- if React didn't double-render the component, it wouldn't break. That's why using the production bundle "fixes" things.

The truth is that side effects like this might cause things to break even outside of strict mode. The upcoming "concurrent" rendering mode is one such case, but it's not the only one. A component might render twice between commits even in "legacy" (synchronous) rendering mode in the event of an error. (In that case, React would bubble the error up to the nearest error boundary, then re-render before committing.)

[amanmahajan7]

Thank you @bvaughn for the quick reply and detailed explanation.

[gmoniava]

Since the ref was mutated during the first render, it's already the same as the "new" prop

@bvaughn when react renders second time intentionally due to strict mode, does it keep the value of ref from previous render, is that what you say? I had a similar situation: https://stackoverflow.com/questions/69393312/state-is-not-updated-in-strictmode, and I thought on second render react discarded the ref value too (hence when I used ref in my question instead of external variable, it seemed to work).

[bvaughn]

Ref isn't changed between regular and strict renders. Shouldn't matter.

Your example code has a side effect (setTimeout) which should not happen in render. Move this to an effect.

[gmoniava]

@bvaughn in my question if you rendered it without strict mode, you would see Paul on screen. If you rendered it with strict mode, you'd see Nick. We thought this was due to using firstRender external variable. firstRender gets modified during first render, and on next strict render, it has different value, hence the second time timeout doesn't fire- and always Nick is printed. Do you agree with this?

If yes, then I found out that by replacing firstRender with a ref, even in strict mode, the output would be now the expected Paul. user ray suggested this could be because unlike firstRender variable, the ref was reinitialized on the second strict render. Hence on the second render the timeout was trigerred. Do you agree with this?

Check the answer and comments.

[bvaughn]

Reading or writing from external values during render is a side effect and is not supported in React components for reasons explained here:
https://reactjs.org/docs/strict-mode.html#detecting-unexpected-side-effects