fix: text field onChange event incorrectly firing when wrapped as React component

[hawkticehurst]

🐛 Bug Report

Passing along a report from @mattrothenberg who is using the VS Code toolkit React components in the GitHub Next Flat Editor extension. (Matt if I miss anything in this bug report feel free to chime in and add details).

The short version is that he's run into an issue where the onChange event handler is firing at incorrect times based on React event standards (which, to be clear, stray from native change event standards).

In React land, this event should fire for every keystroke in the text field. However, this event is only firing when blurring away from the focused input (which, again, correctly follows the native change event standard).

The hope is that there might be some way to adjust the behavior of onChange when defining/using the React-based toolkit components while keeping the regular/default change event behavior in the toolkit web components?

💻 Repro or Code Sample

// Change event follows native standards and only fires when component loses focus
// This strays from React conventions where onChange should fire on every keystroke
<VSCodeTextField onChange={handleChange}></VSCodeTextField>

🤔 Expected Behavior

When wrapped in the fast-react-wrapper, fast foundation components should adjust the behavior of the onChange/change event to follow the conventions of React.

😯 Current Behavior

When wrapped in the fast-react-wrapper, fast foundation components follow the behavior of the native change event.

💁 Possible Solution

Matt discovered there's a solution of using the onInput event to achieve the desired result of "fire event on every keystroke." If needed we're happy to just document this reality and tell people to use onInput instead of onChange.

// This achieves the behavior expected of the onChange event
<VSCodeTextField onInput={handleChange}></VSCodeTextField>

🔦 Context

🌍 Your Environment

n/a (if needed Matt can provide info)

[hawkticehurst]

Oh also for those not using Chromium-based browsers the links referencing the respective React and native change event standards were links to specific text highlights that included the following:

React reference:

Since handleChange runs on every keystroke to update the React state, the displayed value will update as the user types.

Native reference:

Depending on the kind of element being changed and the way the user interacts with the element, the change event fires at a different moment:

• ... other text ...
• When the element loses focus after its value was changed, but not committed (e.g., after editing the value of <textarea> or ).

[EisenbergEffect]

Honestly, I'm not sure if we can change this or even if we'd want to. The web components inputs offer two events: change that happens on blur and input that happens on keystroke, per the HTML standard pattern. The trouble here is that React is fighting against the way that HTML is designed to work and is overriding the native behavior of change events. My recommendation would be to use the input event when you want updates on key press.

[mattrothenberg]

Thanks for your feedback @EisenbergEffect! Hooking into the input event is a perfect workaround for the React components. We will clarify the usage with good docs 👍

[hawkticehurst]

Exactly what @mattrothenberg said!

Thanks for the input (no pun intended)--happy to just update the guidance in our docs on this matter.

Also going to go ahead and close this issue (unless you have a reason for keeping it open in which case I can reopen it).