The event-valuechange module adds a "valuechange" event that fires
when the value property of an <input> or <textarea> element changes as
the result of a keystroke, mouse operation, or input method editor (IME)
input event.
What's the problem?
The input related events provided by browsers don't cleanly address the
variety of ways users can modify an <input> or <textarea>'s
value. For example, users might change an input value by:
- typing a simple character
- typing a multi-stroke character
- using an Input Method Editor
- cutting from or pasting into the value with
Ctrl+XorCmd+V - cutting or pasting with a keyboard-summoned context menu
- cutting or pasting from the right-click context menu.
The ideal change event would fire when the value becomes something it wasn't a moment ago.
The valuechange event provides more reliable input notifications than
native events like oninput and textInput, particularly with changes that
result from multiple-keystroke IME input.
commentTextarea.on('valuechange', updateLivePreview);
How it works
valuechange subscriptions monitor the element's value using a variety of
mechanisms including subscriptions to focus and various keyboard events, and a
poll to catch the stragglers. It seems like a lot of work, but it's the only
way to be sure.
Polling is only active when the element is focused, and only one element is polled at a time, so the performance of your app should not be impacted.
Caveats
-
valuechangeonly supports subscriptions on<input>and<textarea>elements, although it doesn't prevent you from subscribing on other types of elements. If you subscribe on a different type of element and stuff breaks, you were warned. -
valuechangedoes not capturevalueupdates done in JavaScript unless the input is currently focused and polling. It's meant to capture changes made by the user, not by other code. So:node.set('value', 'probably will not trigger valuechange');