onChange doesn't fire if input re-renders due to a setState() in a non-React capture phase listener

[gaearon]

Extracting from #12643.

This issue has always been in React. I can reproduce it up to React 0.11. However it's probably extremely rare in practice and isn't worth fixing. I'm just filing this for posterity.

Here is a minimal example.

class App extends React.Component {
  state = {value: ''}
  handleChange = (e) => {
    this.setState({
      value: e.target.value
    });
  }
  componentDidMount() {
    document.addEventListener(
      "input",
      () => {
        // COMMENT OUT THIS LINE TO FIX:
        this.setState({});
      },
      true
    );
  }
  render() {
    return (
      <div>
        <input
          value={this.state.value}
          onChange={this.handleChange}
        />
      </div>
    );
  }
}

ReactDOM.render(<App />, document.getElementById("container"));

Typing doesn't work — unless I comment out that setState call in the capture phase listener.

Say the input is empty and we're typing a.

What happens here is that setState({}) in the capture phase non-React listener runs first. When re-rendering due to that first empty setState({}), input props still contain the old value ("") while the DOM node's value is new ("a"). They're not equal, so we'll set the DOM node value to "" (according to the props) and remember "" as the current value.

Then, ChangeEventPlugin tries to decide whether to emit a change event. It asks the tracker whether the value has changed. The tracker compares the presumably "new" node.value (it's "" — we've just set it earlier!) with the lastValue it has stored (also "" — and also just updated). No changes!

Our "a" update is lost. We never get the change event, and never actually get a chance to set the correct state.

[Kachulio1]

@gaearon I would love to take this one whats the difficulty level?

[gaearon]

I’m not sure but since it has always been broken I guess it’s not the easiest one. I’m not even sure it can be solved nicely.

[whs-dot-hk]

@gaearon Can it be solved by passing the input value at that moment along before running setState?

react/packages/react-reconciler/src/ReactFiberClassComponent.js

Lines 174 to 190 in 672e859

	enqueueSetState(inst, payload, callback) {
	const fiber = ReactInstanceMap.get(inst);
	const currentTime = requestCurrentTime();
	const expirationTime = computeExpirationForFiber(currentTime, fiber);
	const update = createUpdate(expirationTime);
	update.payload = payload;
	if (callback !== undefined && callback !== null) {
	if (__DEV__) {
	warnOnInvalidCallback(callback, 'setState');
	}
	update.callback = callback;
	}
	enqueueUpdate(fiber, update);
	scheduleWork(fiber, expirationTime);
	},

[gaearon]

Maybe, I haven't dived deep into it. Send a PR?

[whs-dot-hk]

Sorry I can't figure out another way but add another snapshot argument, which is ugly... so let it be

[vinay72]

Instead of using this onChange={this.handleChange}, you can use onChange={event => this.handleChange(event.target.value)} />

[arkakkar]

The issue here is not only because of non-React capture phase listener . I have a separate use case reproducing the same issue, since react makes batch updates to state once per event handler so if multiple events are attached (eg onKeydown and onChange) here onKeydown handler triggers a state update using the useReducer hook which in turn triggers a re-render thus re-setting the updated/changed DOM node value to what is present in the state thus not firing onChange event at all.
These two changes worked for me

1. replacing the onKeydown with onKeyup thus triggering it after the onChange event
2. handling the keyDown handler in an async way, refer to this for more details https://reactjs.org/docs/events.html#event-pooling

onKeyDown = {(e) => { e.persist(); setTimeout(() => { this.onKeyDown(e) }, 0); }}

[owenDods]

Oh man, I wish I'd stumbled across this thread earlier - was banging my head against this issue for a while and thought I was going insane.

I managed to reproduce my simplified use case here.

I have an application where I've started to add in keyboard shortcuts, hence why I was making use of document.addEventListener as well as other form inputs on the page.

What I was seeing in my app while I was trying to debug this really confused me. When I added debugger statements within the relevant useEffect hook I could see the text appear in the input then disappear within the useEffect hook's cleanup function - all without firing the input's onChange.

While I appreciate that it might not be pragmatic to try and fix what might be considered an "extremely rare" issue; how realistic would it be to add a warning for users about this potential conflict? Maybe even just adding a "N.B." to the documentation?

When I searched for "addEventListener" on the reactjs.org site it took me to Handling Events. Maybe a note here could save people some hassle? Or making a "Gotchas" page for known edge-case issues like this that are known but aren't going to be fixed anytime soon?

In any case, thanks for filing this issue in the first place - it gave me some much needed closure!