Any known issues with nested forms?

[silverdr]

This is more like a question but I wasn't able to get live_select input working in a form where the inputs are inside inputs_for block rather than top level of the form. I can't exclude that I did something incorrectly but the live_select_change event handling function was never called. If you could be so kind as to let me know whether this type of use case is fully supported and should work?

[maxmarcon]

Hi! The use case with inputs_for should work. I assume you were able to get the component to work otherwise, and it stopped working once you used the component inside the inputs_for block? If so, I might be able to help if you share some code.

I can't exclude that I did something incorrectly but the live_select_change event handling function was never called

is the live_select_change event being fired, but your event handling function is not called? In that case, it could be that you didn't specify the right component by using the phx-target assign (i.e. the event is being sent to the wrong component).

[silverdr]

I assume you were able to get the component to work otherwise, and it stopped working once you used the component inside the inputs_for block?

I checked the demo and tried to include live_select in my form, where I need it in the nested part. The form is a LiveView (use NvoiceWeb, :live_view), meaning I don't use the phx-target={@myself} (even if I tried, that would not work but complain about "myself" not being available)

I might be able to help if you share some code

The form looks basically as follows:

<.form :let={f} for={@changeset} action={@action} phx-change="handle_change" phx-submit="submit">
    [… here the top level stuff / inputs / labels / ...]
    <.inputs_for :let={fli} field={f[:nested_fields]}>
        <div id={"line_#{fli.index}"} class="<here some tw stuff">
            <span class="md:w-7/12">
                <.live_select form={fli} field={:description} />
                [...]

Upon keypresses I saw events flowing in the log but no results and nothing about live_select_change and putting some debug into the handler function confirmed that it wasn't called.

FWIW - the "classic" (<%= inputs_for […] %> and <%= form […]) behaved the same

[maxmarcon]

Thanks for the details. If you don't even see live_select_change being fired in the logs then probably the JS hooks aren't working (the event is fired from there). Did you add the hooks as described here?

[silverdr]

Without hooks it complains about unknown hook. Since I have other hooks and they were added following the style from LiveView documentation I added it a bit differently than in your docs but here's the output of console.log(Hooks); I assume that's correct, isn't it? And it does not complain about unknown hook either. BTW - those keypress events in the log were certainly not "mine" they must have come from your code.

[maxmarcon]

yes that looks correct indeed.

If the hook is correctly mounted (which appears to be the case since as you say it's not complaining about unknown hooks) then after typing a few characters in the live_select text input you should see a live_select_change event in the LV logs.

Something like this:

[debug] HANDLE EVENT
  View: LiveSelectWeb.ShowcaseLive
  Event: "live_select_change"
  Parameters: %{"field" => "city_search", "id" => "my_form_city_search_live_select_component", "text" => "abc"}

Absolutely sure you don't see anything like that?

Maybe also try to move the live_select out of the inputs_for loop and see if it changes anything.

[silverdr]

What I was seeing was only this:

[debug] HANDLE EVENT "focus" in PhxAppWeb.ItemFormLive
  Component: LiveSelect.Component
  Parameters: %{"value" => ""}
[debug] Replied in 1ms
[debug] HANDLE EVENT "keydown" in PhxAppWeb.ItemFormLive
  Component: LiveSelect.Component
  Parameters: %{"key" => "KeyA"}
[debug] Replied in 67µs
[debug] HANDLE EVENT "change" in PhxAppWeb.ItemFormLive
  Component: LiveSelect.Component
  Parameters: %{"_target" => ["item", "subitems", "0", "description_text_input"], "item" => %{"subitems" => %{"0" => %{"description_text_input" => "a"}}}}
[debug] Replied in 182µs
[debug] HANDLE EVENT "keyup" in PhxAppWeb.ItemFormLive
  Component: LiveSelect.Component
  Parameters: %{"key" => "a", "value" => "a"}
[debug] Replied in 131µs
[debug] HANDLE EVENT "blur" in PhxAppWeb.ItemFormLive
  Component: LiveSelect.Component
  Parameters: %{"value" => "a"}
[debug] Replied in 87µs

so definitely nothing like the expected event! But… after reading your

after typing a few characters in the live_select text input

I continued to type beyond what I did before, and…

[debug] HANDLE EVENT "live_select_change" in PhxAppWeb.ItemFormLive
  Parameters: %{"field" => "description", "id" => "item[subitems][0]_description_live_select_component", "text" => "afew"}

Gosh! My bad :-( I didn't think and didn't notice that it (update_min_len) "Defaults to 3". I apologise and thank you for your support and patience!

On a side-note - Does it always send so many events over the wire or is it due to some "debug mode" being on currently?

[maxmarcon]

Gosh! My bad :-( I didn't think and didn't notice that it (update_min_len) "Defaults to 3". I apologise and thank you for your support and patience!

No worries. In fact, you made me realize that the default value for that option may be a source of confusion - I changed it to be 1.

On a side-note - Does it always send so many events over the wire or is it due to some "debug mode" being on currently?

Yes it does need all the events. keyup and keydown to track what is being input and arrow keys for dropdown navigation, esc key, etc. blur and focus to decide when to hide/show the dropdown and a few others as well.