Javascript 在 React 中，onChange 和 onInput 有什么区别？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/38256332/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
In React, what's the difference between onChange and onInput?
提问by ffxsam
I've tried searching around for an answer to this, but most of them are outside the context of React, where onChangetriggers upon blur.
我试过四处寻找答案，但大多数都在 React 的上下文之外，onChange在模糊时触发。
In performing various tests, I can't seem to tell how these two events are different (when applied to a textarea). Can anyone shed some light on this?
在执行各种测试时，我似乎无法分辨这两个事件有何不同（当应用于 textarea 时）。任何人都可以对此有所了解吗？
采纳答案by Stijn de Witt
It seems there is no real difference
似乎没有真正的区别
React, for some reason, attaches listeners for Component.onChangeto the DOM element.oninputevent. See the note in the docs on forms:
出于某种原因，React 为Component.onChangeDOMelement.oninput事件附加了侦听器。请参阅表单文档中的注释：
There are more people that are surprised by this behavior. For more details, refer to this issue on the React issue tracker:
有更多人对这种行为感到惊讶。有关更多详细信息，请参阅 React 问题跟踪器上的此问题：
Document how React's onChange relates to onInput #3964
记录 React 的 onChange 如何与 onInput 相关 #3964
Quote from the comments on that issue:
引用关于该问题的评论：
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 not 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.
我不明白为什么 React 选择让 onChange 表现得像 onInput 那样。据我所知，我们无法恢复旧的 onChange 行为。文档声称这是“用词不当”，但事实并非如此，它会在发生变化时触发，直到输入也失去焦点。
对于验证，有时我们不想在输入完成之前显示验证错误。或者我们只是不想在每次击键时重新渲染。现在唯一的方法是使用 onBlur 但现在我们还需要检查该值是否已手动更改。
这没什么大不了的，但在我看来，React 扔掉了一个有用的事件，并在已经有一个这样做的事件时偏离了标准行为。
I agree 100% with the comment... But I guess changing it now would bring more problems than it solves since so much code had already been written that relies on this behavior (and it has also been copied to other frameworks, e.g. Preact).
我 100% 同意评论......但我想现在改变它会带来比它解决的更多的问题，因为已经编写了这么多依赖于这种行为的代码（并且它也被复制到其他框架，例如Preact） .
React is not part of the official Web API collection
React 不是官方 Web API 集合的一部分
Even though React is built on top of JS, and has seen a huge adoption rate, as a technology React exists to hide a whole lot of functionality under its own (fairly small) API. Once area where this is obvious is in the event system, where there's a lot going on under the surface that's actually radically different from the standard DOM event system. Not just in terms of which events do what, but also in terms of when data is allowed to persist at what stage of the event handling. You can read more about that here:
尽管 React 是建立在 JS 之上的，并且已经看到了巨大的采用率，但作为一项技术，React 的存在是为了将大量功能隐藏在自己的（相当小的）API 下。在事件系统中，这一点很明显，在表面下发生的很多事情实际上与标准 DOM 事件系统完全不同。不仅涉及哪些事件做什么，还涉及何时允许数据在事件处理的哪个阶段持久化。您可以在此处阅读更多相关信息：
回答by Nikhil Goyal
There is no difference
没有区别
React does not have the behaviour of default 'onChange' event. The 'onChange' which we see in react has the behaviour of default 'onInput' event. So to answer your question there is no difference in both of them in react. I have raised an issue on GitHub regarding the same and this is what they have to say about it:
React 没有默认 'onChange' 事件的行为。我们在 react 中看到的 'onChange' 具有默认的 'onInput' 事件行为。因此，要回答您的问题，两者的反应没有区别。我在 GitHub 上提出了一个同样的问题，这就是他们不得不说的：
I think that at the time this decision was made (~4 years ago?), onInput didn't work consistently between browsers, and was confusing to people coming to the web from other platforms, as they would expect the “change” event to fire on every change. In case of React it is a bigger issue because if you fail to handle change soon enough, the controlled inputs never update, leading people to think React is broken. So the team went with calling it onChange.
In retrospect it might have been a better idea to polyfill onInput and keep its name rather than change the behavior of another event. But that ship has sailed a long time ago. We might revisit this decision in the future, but I would just encourage you to treat it as a quirk of React DOM (which you'll get used to pretty quickly).
我认为在做出这个决定的时候（大约 4 年前？），onInput 在浏览器之间不能一致地工作，并且让从其他平台访问网络的人感到困惑，因为他们期望“更改”事件在每次更改时触发。在 React 的情况下，这是一个更大的问题，因为如果您不能尽快处理更改，则受控输入永远不会更新，导致人们认为 React 已损坏。因此，该团队将其称为 onChange。
回想起来，polyfill onInput 并保留其名称而不是更改另一个事件的行为可能是一个更好的主意。但是那艘船已经航行了很久了。我们将来可能会重新考虑这个决定，但我只是鼓励你把它当作 React DOM 的一个怪癖（你会很快习惯）。
https://github.com/facebook/react/issues/9567
https://github.com/facebook/react/issues/9567
Also this article will provide more insight and a workaround for default 'onChange'
此外，本文将为默认“onChange”提供更多见解和解决方法
回答by Alan Souza
Recently I got a bug where onChangewould not allow copy and paste in the input field on IE11. Whereas the onInputevent would allow that behavior. I could not find any documentation that would describe this in the docs, but that does show there is a difference between the two (expected or not).
最近我遇到了一个错误，即onChange不允许在 IE11 上的输入字段中进行复制和粘贴。而onInput事件将允许这种行为。我在文档中找不到任何可以描述这一点的文档，但这确实表明两者之间存在差异（预期与否）。
回答by chad steele
As you can see in various comments here, React treats onChange and onInput the same and so, rather than debate the merits of this decision. Here's the solution.
正如您在此处的各种评论中看到的那样，React 将 onChange 和 onInput 视为相同的，而不是争论这个决定的优点。这是解决方案。
Use onBlur when you don't want to process the user's edits until they're done. :)
当您不想在用户编辑完成之前处理它们时，请使用 onBlur。:)
