Changes to form handling in Phoenix LiveView 0.18.14

Hey, this recent commit removes the :errors attribute from the <.form> component and now this code raises a warning about non-existent errors attribute:

<.form :let={form} for={@conn} action={~p"/foobar"} as={:foo} errors={@errors}>

What I’m doing here is using the form component in a regular (non-live) view and managing the errors without a changeset. The code still works, because AFAIK it calls to_form underneath.

  1. Was this an intentional change? cc @josevalim as the author of the commit.
  2. Should I now use to_form explicitly moving forward?
  3. The docs now mention using conn.params instead of Plug.Conn as a potential source for form data. Should I now start doing for={@conn.params} instead?

Last time I checked there were some ideas to change how Phoenix (LiveView) approaches forms (also form[field] instead of {form, field}) and it seems this is related to that. Is there any writeup on the new approach?

1 Like
  1. Just reverted, thanks. We added the feature back later but I skipped the declarative assign bit. Please test and let me know!

  2. Not necessary, it is optional.

  3. From now on, yes. We are unifying as for={data} as={name}, where data is either a map or a changeset (or a form). Before we could have for={:name}, which was very confusing!

  1. Works with the latest master! Thanks for addressing this!

@josevalim One more thing that I stumbled across: the implementation of the Access behaviour for Phoenix.Form only allows atom keys and that’s unfortunate for working with dynamic fields like so:

<.form :let={form} for={@conn.params} action={~p"/foobar"}>
  <%= for id <- [1, 2, 3] do %>
    <.input type="checkbox" field={form[to_string(id)]} />
  <% end %>

This blows up with a function clause error. Can we get the support for string keys?

BTW I think it was meant to be caught by the second function head, but I’m guessing there’s a typo:

def get(%Form{}, field) do
  raise ArgumentError,
        "accessing a form with form[field] requires the field to be atom, got: #{inspect(field)}"

I believe this should be fetch instead of get.


I thought that was a typo too, but I was getting that exception while doing the upgrade.

Does using the . call fetch and using [] call get? I got lost after tracing it to the special form . where the source told me to bugger off, the compiler handles it.

What I found confusing at first was that get is not part of the Access behaviour, only fetch and get_and_update and pop. However, it seems be be implemented for the form and in Accessible. But if it were, I guess you’d be able to use [] on a struct? It does seem silly to pop on a struct too :slight_smile:

Thank you once more, fixed. <3

I will investigate string fields next.


String fields is on master, please give it a go and let us know if/how it works.


Thanks! Works great!