私はこれに対する答えを探してみましたが、それらのほとんどはReactのコンテキスト外にあり、onChange
はぼかし時にトリガーします。
さまざまなテストを実行する際に、これら2つのイベントがどのように異なるのか(テキストエリアに適用された場合)わかりません。誰でもこれに光を当てることができますか?
Reactは、何らかの理由で、Component.onChange
のリスナーをDOM element.oninput
イベントに関連付けます。フォームに関するドキュメントのメモを参照してください。
この振る舞いに驚く人はもっといます。詳細については、React課題トラッカーでこの問題を参照してください。
ReactのonChangeがonInput#3964とどのように関連するかを文書化
その問題に関するコメントからの引用:
ReactがonChangeをonInputのように動作させることにした理由がわかりません。私が知る限り、古いonChangeの動作を取り戻す方法はありません。文書は、それが「誤名」であると主張していますが、そうではなく、変更があったときに発火します。入力がフォーカスを失うまでは発火しません。
検証のために、入力が完了するまで検証エラーを表示したくない場合があります。または、すべてのキーストロークで再レンダリングしたくないだけかもしれません。これを行う唯一の方法はonBlurを使用することですが、値が手動で変更されたことを確認する必要もあります。
それほど大したことではありませんが、Reactは有用なイベントを破棄し、これを行うイベントが既にあったときに標準の動作から逸脱したように思えます。
私はコメントに100%同意します...しかし、この動作に依存する多くのコードがすでに記述されているため、それを変更すると、解決するよりも多くの問題が生じると思います(そして、それは他のフレームワークにもコピーされています、例えば- Preact )。
Reactは公式のWeb APIコレクションの一部ではありません
ReactはJSの上に構築されており、非常に高い採用率が見られますが、テクノロジーReactは独自の(かなり小さい)APIの下で多くの機能をすべて隠すために存在します。かつてこれが明らかな領域はイベントシステムにあり、表面では実際に標準DOMイベントシステムとは根本的に異なる多くのことが行われています。どのイベントが何を行うかという点だけでなく、イベント処理のどの段階でいつデータを保持できるかという点でも。詳細については、こちらをご覧ください。
Reactには、デフォルトの 'onChange'イベントの動作はありません。 reactで表示される「onChange」には、デフォルトの「onInput」イベントの動作があります。したがって、あなたの質問に答えるために、反応の両方の違いはありません。私は同じことに関してGitHubで問題を提起しました。
この決定が行われた時点(約4年前?)で、onInputはブラウザー間で一貫して機能せず、「変更」イベントを期待するため、他のプラットフォームからWebにアクセスするユーザーを混乱させていたと思いますすべての変更で起動します。 Reactの場合、変更をすぐに処理できない場合、制御された入力が更新されないため、人々はReactが壊れていると考えるようになるため、これは大きな問題です。そのため、チームはonChangeと呼びました。
振り返ってみると、別のイベントの動作を変更するのではなく、onInputをポリフィルし、その名前を保持することをお勧めします。しかし、その船はずっと前に航海しました。将来、この決定を再検討する可能性がありますが、React DOMの癖として扱うことをお勧めします(すぐに慣れるでしょう)。
https://github.com/facebook/react/issues/9567
また、この記事では、デフォルトの「onChange」に関する詳細な情報と回避策を提供します。
ここでのさまざまなコメントでわかるように、Reactは、この決定のメリットについて議論するのではなく、onChangeとonInputを同じように扱います。これが解決策です。
ユーザーの編集が完了するまで処理しない場合は、onBlurを使用します。 :)
最近、onChange
がIE11の入力フィールドでのコピーと貼り付けを許可しないというバグがありました。一方、onInput
イベントはその動作を許可します。ドキュメントでこれを説明するドキュメントは見つかりませんでしたが、この2つに違いがあることが示されています(予想されるかどうか)。