I’m having an issue with a Phoenix LV form using the new setup where te result of to_form/2 is assigned to @form and passed to the new <.form for={@form} ...> component (through the <.simple_form ...> from the core components).
The schema I’m editing has a few has_ones that I’m casting with cast_assoc/3. Those assocs have some boolean fields that can be toggled in the form. The boolean fields have a logical relations that I’m keeping consistent when creating the changeset (with the regular changeset function of the parent schema, and the changeset functions of the assoc schemas). It’s basically casting everything as usual, and then doing some put_change’es on the assoc structs’s, and then put_assoc on the parent struct to make sure everything is going into the final changeset. Long story short: there is some automization/magic going on when toggling checkboxes to keep everything consistent, on top of the regular casts of the booleans.
I’m sure the final changeset incorporates all the changes that are needed to keep everything consistent just like I want it (I inspected the result).
The <.simple_form ...> resides in a parent LiveView, while the <.inputs_for :let={f_nested} field={@form[:some_field]}> component for each field resides in a LiveView Component within the parent LV (the LV component is rendered with <.live_component form={@form} ...> passing in the @form assign, so it can use it).
What I’m observing is that in some situations, the automatically changed booleans (which render to a checkbox) are not updated with the correct state in the final changeset. There is a difference between the final changeset and what appears on the screen, in the checkbox. I see that the Phoenix.HTML.FormField (which I inspect when rendering the template) behind the assoc’s boolean field also has the wrong value field. I see it has the correct data field (loaded from the DB) and the correct changeset, but the final value field is wrong. A detail that caught my eye is that the value is actually containing "true" (a binary, not a boolean, probably from the initial params field), when it goes wrong. While it has a boolean value (true / false), when all goes well.
I’m at a dead end on how I can investigate this further. My first hypothesis that I broke change tracking seems wrong, because I see that the Phoenix.HTML.FormField struct already has a wrong value. Or maybe I’m using the <.inputs_for :let={f_nested} field={@form[:some_field]}> incorrectly (should I not use the :let={f_nested} attribute and access the assoc field directly somehow?). Maybe it’s useful to notice that I’m actually looping over the fields in the template, with the for comprehension, which should work fine I do this because the fields are very similar and have a very similar markup.
Any suggestions on how to debug this problem is highly appreciated. Maybe I’m bumping on a bug here, combining some new features in a new way? But I doubt it.
(btw, I also tried to debug with the :debugger module, as explained here, but Phoenix is not happy to have the LV process be hanging longer periods of time, and the LV process exits underneath my feet. If that is easily fixable, I can give that a try again. But then still, I wouldn’t know where to step into.)
Learn me to fish this situation 
Sorry for the long read, I tried to convey the essence here 
