4 ms·
In some cases, react seems to go out of its way to make the built-in functionality harder to access. For instance, if you assign "onchange" to an <input>, reac
by recursive 3y ago
In some cases, react seems to go out of its way to make the built-in functionality harder to access. For instance, if you assign "onchange" to an <input>, react will give you the "input" event, not the "change" event. (Actually, it gives a neither. It gives you a "synthetic" event that's closer to input than change) What if you know what you're doing, and you actually wanted "change"? You have to use an element ref an attach the handler using an effect.
- no_wizard 3y agoYou can access the `nativeEvent` property on the event object[0] if you prefer [0]: https://react.dev/reference/react-dom/components/common#react-event-object-properties https://react.dev/reference/react-dom/components/common#reac...
- recursive 3y agoDoesn't solve this problem. "change" fires at different times from "input". `nativeEvent` is useful if you want the real event data object for the event that actually fired. In this case, it's a whole other event.
- 11235813213455 3y agoit's a well known thing in react (preact does it well https://preactjs.com/guide/v10/differences-to-react/#use-oninput-instead-of-onchange https://preactjs.com/guide/v10/differences-to-react/#use-oni...), and probaly a design mistake on their side (now too late to change), I can't think of other cases like that
- recursive 3y agoThey could still expose a `nativeChange` event without breaking backward compatibility.