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).

Chiming in here with several use cases we have run into while developing our app.
We use Surface heavily which pushed us a lot into using live_component. Which worked great… Until we realized that we cannot handle any input changes inside our live_component without adding a form. And as soon as we try to put live_component inside another form it all breaks as forms cannot be nested based on HTML5 specification.

We have many autocomplete and select fields and need to resort to writing lots of custom hooks with push events through alpine just to work around it.
I do feel that it shows that the current implementation of live_component needs more work. Specifically, the change event based on HTML5 specification is raised on the element, not on the form. It only bubbles to the form:

When the user agent changes the element’s value on behalf of the user (e.g. as part of a form prefilling feature), the user agent must follow these steps:

1. If the input event applies, queue a task to fire a simple event that bubbles named input at the input element.
2. If the change event applies, queue a task to fire a simple event that bubbles named change at the input element.

A simple use case that is trivial in React or even plain javascript seems quite problematic to make work with live_component.
We have a live_component with pairs of select input and text input. When a certain select value is selected the input field should be hidden. Right now we hack it with this:

<Select
              class="w=1/3 border bg-white rounded py-2 outline-none"
              options={space_type_options(index)}
              opts={
                "x-model": "selectedType",
                id: "subpremiseSelector2",
                "phx-hook": "Inputs.SubpremiseInputs#subpremiseInputs",
                "x-on:change": "subpremiseInputs.pushEventTo($el, 'type_changed', $el.value)"
              }
            />

    <div data-show={@show} x-show="selectedType!=$el.dataset.show">
            <Field name={:value}>
              <TextInput class="border bg-white rounded py-2 outline-none" opts={hook: "subpremiseInputs"} />
              <ErrorTag />
            </Field>
          </div>

# the hook
let subpremiseInputs = {
  mounted() {
    window.subpremiseInputs = this;
  },
};

window.subpremiseInputs = subpremiseInputs;
export { subpremiseInputs };

Being able to just have phx-change on select and handle_event inside the live_component would remove the need for custom hook hacking and adding alpine magic where its not necessary needed.

And also the relevant section here: Form bindings — Phoenix LiveView v1.2.5

image1200×626 48 KB