Document how React's onChange relates to onInput

[graue]

It would be nice for the Forms doc to be more explicit about the fact that React's onChange supersedes, and should generally be used in place of, the DOM's built-in onInput event. People might be used to using onInput instead for text inputs and textareas, since, with the raw DOM, the change event for these controls doesn't fire until the control loses focus.

[AnSavvides]

Opened a PR to address this: #4003

[AnSavvides]

Merged, hurray, we can close this now! 🎉

[sunyang713]

wait but why?

[mnpenner]

Yeah...why? I don't understand why React chose to make onChange behave like onInput does. As fas as I can tell, we have no way of getting the old onChange behaviour back. Docs claim it's a "misnomer" but it isn't really, it does fire when there's a change, just not until the input also loses focus.

For validation, sometimes we don't want to show validation errors until they're done typing. Or maybe we just don't want a re-render on every keystroke. Now the only way to do that is with onBlur but now we also need to check that the value has changed manually.

It's not that big of a deal, but it seems to me like React threw away a useful event and deviated from standard behaviour when there was already an event that does this.

[evpozdniakov]

Agree with mnpenner.

With onChange fireing on every keystroke, my redux store changes simultaneously. To avoid that, I have to use onBlur.

Finally, we have two events - onInput and onChange - which work same manner.

[piotr-cz]

Besides there is no easy workaround to replicate such behaviour for the <input type="range" /> element.

Native events behave such way that moving the slider around triggers an onInput event and releasing it triggers onChange.