React: 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! :tada:

[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.

[bcherny]

Another note: Autofill events (at least on Chrome/OSX) trigger onInput, but not onChange! So if I want to capture a change event to an input that might be filled using Chrome's autofill feature, I need to bind to both onInput (to detect keystrokes and autofill) and onChange (to placate React [1]).

[1]

Warning: Failed form propType: You provided a value prop to a form field without an onChange handler. This will render a read-only field. If the field should be mutable use defaultValue. Otherwise, set either onChange or readOnly. Check the render method of StatelessComponent.

[ddelrio1986]

@mnpenner, @evpozdniakov for validation messages or things that you want to wait until they stop typing for use debounce in your event handler instead of waiting until onBlur.

[fabiosantoscode]

Still no way of using onChange? I've been writing lots of logic to get around not having a real change event.

I think to be a better abstraction, React needs to stick to onChange and let us use onInput without a silly warning.

Validation has never been this hard.

[graue]

For better or worse, this has been the behavior for quite a while, and many React users rely on it.

IMHO, it's probably too late in the game to totally change what "onChange" means in React. But if you feel strongly, maybe do a quick PR to propose a solution with a sensible upgrade path? (Before spending a lot of time on it, get the thoughts of the core team.)

[fabiosantoscode]

Right @graue, I've suggested #14857 instead to create a new event and minimise breaking changes.

[alamothe]

Definitely a huge design issue with React. Hope it doesn't stay this way forever

[qtv100291]

This is a mistake or a feature :/

[milessorce]

This is a mistake or a feature :/

Features are supposed to be useful... this is the opposite of useful.