If you are ok to alter the shown component, you can add phx-click={JS.push("selected_option", value: %{id: id})} on the “drop down option div”, which would ping an event out for each separate option cilck. You would have to track the remove event separately and do all the list maintenance yourself. You could wrap this in an functional component.
You could also adjust the given component to dispatch a custom event when a selection change occurs, and that event could contain all the options selected. Have a hook that catches that and pushes all the options in one go. There was a talk at this years ElixirConf about using custom html components which would fit this very well if you wanted to drop alpine. I assume this is what you’ve basically already done.
Or you could generate a small form inside the dropdown with alpines x-for, with hidden inputs and generate a submit event on it when selection changes and use the normal phx-submit/change stuff. This will have issues embedding in other forms but you could just use the form it’s embedded in in that case.
The hooks probably the easiest to maintain in the end I think. One event with the whole set of selected options. Phoenix LiveViews provided events aren’t designed to be “input specific” (i.e. you cant phx-change on an <input>), so it’s not really designed to work like LiveWire’s model binding, I would think.
I just stumbled upon that livewire post and thought, that they have a simple way to just send arbitrary events to the server - I’d like to have that for LV. With LV the only way to do this is with a hook (right?). The hook is OK, but the element I need in the HTML is a little annoying.
But I think I did not understand the livewire solution right, they just simulate an input event. I can do the same with LV:
the alpine component uses a hidden select, use a Phoenix.HTML.multiple_select for this
reflect all the selected options in the hidden <select> by toggling <option selected ...>