Phoenix.HTML.Form.field_value/3 does not return then change when given a Ecto.Changeset about phoenix_ecto HOT 6 CLOSED

No, that did not fix it. I added a test to describe the behaviour I am after. Correct me if I am wrong:

• Look in the changes,
• if nothing is there, look in the params,
• if nothing is there, look in the data,
• if nothing is there, return the default value or nil.

I'll see if I can make the changes.

from phoenix_ecto.

I can't fix it in this repo. This behaviour needs a change in phoenixframework/phoenix_html.

The precedence now is: params -> default -> changes -> data.

This feels wrong, especially that the default value is taken before the changes or actual data.

I think the precedence should be: changes -> params -> data -> default.

from phoenix_ecto.

@ThijsWouters can you please check Ecto master?

You are correct except by the default which should have higher preference than the data because the default often uses a value computed on top of the data.

from phoenix_ecto.

@josevalim Taking the default over the data does not make sense to me.

Let's say we have a transaction with a date. We want a default date of today.

So you say that when we start to edit the transaction, the date field is not filled with the previously chosen date, but with the current date?

from phoenix_ecto.

The default is used for cases where you want to use a value that was computed on top of the data value, hence you want it to have higher precedence:

input_value(form, :name, String.upcase(data.name))

If you really want a value if nothing else was set then you can do this:

input_value(form, :name) || "fallback"

Maybe it is a matter of giving it a better name than default, such as "computed".

Changing it would also be backwards incompatible, so finding a better way to describe is the best way to go.

Did the rest work as expected on master?

from phoenix_ecto.

It does work as expected on master, thanks.

default is indeed a confusing name for something like this.

from phoenix_ecto.