Add `phx-input` binding to LiveView

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

Does phx-change work?

1 Like

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

:exploding_head: 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.