Add event that behaves similar to the native change event

[dantman]

Because React has repurposed onChange to behave like onInput there is no way to get actual change event behaviour without binding a non-delegated native event in lifecycle events.

change event behaviour is sometimes important to have. input-like behaviour does make sense for what React uses onChange for (live updating of state associated with value="" and anything derived from it). But other use cases, like triggering an ajax post once a user has finished with an input, require the standard behaviour of change for text inputs where it is only fired after a user is finished with the input.

These use cases are reasonable to support within React. If onChange is going to be changed to behave in a non-standard way. Then we should add another custom non-standard event name that lets React elements bind to behaviour that is closer to how change behaves (with React's event delegation handling).

Event name ideas:

• onChangeCommit(ted)
• onCommit(ted)Change
• onValueCommit(ted)
• onCommitValue
• onCommit?

The idea of using "commit" in the name comes from the HTML spec.

The change event fires when the value is committed, [...]

~ Section 4.10.5.5 Common event behaviours

[sophiebits]

We've suggested in the past binding to onBlur if that's the semantics you want. Does that work for you?

[dantman]

onBlur fires on every blur even if nothing has changed.

Why should developers have to fake an event behaviour when a native standard event has that exact behaviour?

[Andreyco]

I am in this situation too very often.
Standard events offer perfect control over reading value of input.

Very good example is Range input. onInput is triggered continuously, while dragging handle.
https://jsfiddle.net/69dqhmcc/1/. onChange on blur or drag end.
In React, both events are triggered at very same time. https://jsfiddle.net/69z2wepo/25123/

I understand React's way of handling input/change events simplifies things. With only onChange handler you are subscribed to live updates.

What's the reason behind this decision? Is it even possible to move closer to standard behaviour at this stage?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.

[stale]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!