I highly appreciate your engagement and willingness to help but I probably was not clear or explicit enough because the answers to your questions are in fact up there.
f is correct and holds correct Phoenix.HTML.Form struct. It works, fields are pre-filled with values taken from the data source (RDBMS)- I do not pass nil. I pass the model / changeset and since the form is constructed correctly and works, there is no way that there is nil being passed but I’ll do a quick “crowbar” style test below in order to prove it
- As mentioned already, this is editing an existing record so I don’t expect things to be in
params but again I’ll do the test
- (Edit) -
Decimal.normalize/1 cannot return nil value. True. And I didn’t write that it returned nil. I wrote that:
Now for the quick “crowbar” test. Let’s put value: f.nonexistent into the input line. Result:
key :nonexistent not found in: %Phoenix.HTML.Form{
source: #Ecto.Changeset<action: nil, changes: %{}, errors: [],
[...]
data: %MyApp.MyContext.MyModel{
[...]
field: Decimal.new("123.45000000"),
[...]
},
action: nil,
hidden: [{"_persistent_id", "0"}, {:id, 124}],
params: %{"_persistent_id" => "0"},
errors: [],
options: [multipart: false],
index: 0
}
So the form is correct, the form variable f is correct. The form struct’s data contains the field and field contains correct, non-nil value. And yet we are talking about a Schrödinger field’s value. If I don’t touch it - it is there:
value: f.data.field yields correct value
If I try to touch it - it disappears:
value: Decimal.normalize(f.data.field) yields:
no function clause matching in Decimal.normalize/1
[...]
Called with 1 arguments
1. nil
value: Decimal.normalize(input_value(f, :field)) yields:
no function clause matching in Decimal.normalize/1
[...]
Called with 1 arguments
1. nil
even more interesting: value: [Decimal.normalize(input_value(f, :field))] yields:
lists in Phoenix.HTML and templates may only contain integers representing bytes, binaries or other lists, got invalid entry: Decimal.new("123.45")
showing exactly what was supposed to be there…
Now, all of those may be a kind of an unexpected side effect of trying to do it all the wrong way (as my guts try to tell me) so my original question remains:
UPDATE 0: I begin to suspect that this appearing/disappearing value may somehow be caused by LiveView rendering the page twice… but even if I find it to be true then I am still unsure if there is no better approach for the problem at hand
The field in question is in 
Although not exactly a nested form’s problem but rather me adding an unwanted/unexpected collection member where it wasn’t meant to be. And masquerading this fact with some crashes 
