Today we require the phx-change to be on the parent form, not individual inputs

Thank you for the reply. Is this a design choice or it will probably be added in a near future?

At the moment I’m not planning on making it per input because you can get what you want with the form events, and every event will have all the form input so it’s generally a better approach.

Doesn’t that mean you can’t quite as easily have composible form elements? Instead you’ll need to compose everything manually in code for each given form and all possible fields that it might dynamically have. In Drab I just use a drab child commander to add those and it is all very compartmentalized, so this would be a very useful feature in liveview.

I need to see concrete use cases first before settling on a broader API. Having the top-level form control its input is preferred because it’s generally what you want event wise, where a single change event provides the current client form state. More critically, it also allows us to more easily control the loading/disabled/patch states of form events where ad-hoc components make this more difficult, and open up race conditions to a programmer concern instead of library concern. For example, LV can lock the form or defer patches to the form before a server acknowledgement from the pushed form event, where ad-hoc inputs would not. So my current preference is to nail down the loading state and deferred patch handling at the form level and see if we need to go further from that base.

My initial thought is an autocomplete input, I want the input code to handle that, not the form itself as it doesn’t care, and adding that to every form’s handler just in the off chance the autocomplete version is used in the HTML is extra mental bandwidth to handle, plus however many other plugins the overall system will include over time. The autocomplete input is the precise use that I use a drab submodule for. In HTML all I have to do is craft an html element with special drab-* attributes and it auto-registers and hooks in the child commander, which uses the information in the attributes to know which autocomplete list to pull from (which can even push updates in real time without typing changes if the autocomplete list has backend changes).

Why can’t you just use phx-keyup for individual form elements? That’s what I’m using and it works great.

You can, but you still have to tie it into the backend somehow, the frontend is not the issue. ^.^

phx-keyup will pass the value of the input to the handle_event function which you can use to return the autocomplete options. Is that what you are trying to do?

Not me, I’m referencing putting in pre-built blocks into a page. For example, drab allows you to do something like <div drab-commander="MyCommander">...</div> and the div and everything in it is controlled by an entirely different commander (like a liveview socket) rather than the main one, allowing you to break up functionality and re-use it in a trivial manner.

Though perhaps you meant to reply to the OP rather than my post? ^.^;