I notice that most events have bindings (e.g. phx-keyup
) but not the input
event.
The input
event is the preferred way to interact with an input. For a text input, the keyup
and input
events will typically correspond, but not always. Example: pressing arrow keys, or command-A triggers keyup
but no input
. Selecting the “Cut” or “Paste” menu items will generate an input
even but no keyup
.
2 Likes
No, input
is triggered for every changes, before they are “committed”, while change
is triggered when it’s committed (e.g. you tab out the text field). That’s why I compared it to keyup
; you might get a bunch of keyup
before there’s a change
event.
Another example, the color input presents a modal with a color wheel. It triggers input
events whenever you select a color, and change
only when you click on “ok”.
1 Like
phx-change
on a form or input is effectively the input
listener. (We literally bind to "input"
), so phx-change should give you what you want.
3 Likes
Oh, you are both right, thanks. TIL.
Note that I couldn’t find this information anywhere in the doc.
Please consider renaming the hook phx-input
as it is literally what it does. Looking at the source, there’s binding on both “input” and “change”, with de-dupping that should actually never use the “change” binding, unless the user triggers manually a “change” event without an “input” event to precede it (in which case the next “input” event will actually be wrongly ignored by phoenix)
I believe this PR fixes the potential minor issue I was mentioning.
I am with you.
Your observation about renaming the phx-change
to phx-input
makes sense, considering the underlying binding to the “input” event. It would also provide clarity and consistency for developers when reading the code and documentation.