Phoenix.Component.inputs_for/1 Ignores id and index from Phoenix.HTML.Form struct

[woylie]

I posted this before on Elixir Forum before, but didn't get any response. I'm not sure whether this is a bug or whether there's a reason behind the current implementation, so please excuse me for posting the same question here.

---

Flop.Phoenix implements the Phoenix.HTML.FormData protocol for its meta struct: https://github.com/woylie/flop_phoenix/blob/main/lib/flop_phoenix/form_data.ex.

At some point, an offset option was added to allow users to build more complex form layouts. By setting the option, the :index, :id, and :name fields on the Phoenix.HTML.Form struct are set in to_form/4:

offset_string = Integer.to_string(offset)

%Phoenix.HTML.Form{
  index: offset,
  id: id <> "_" <> offset_string,
  name: name <> "[" <> offset_string <> "]",
  # ...
}

This worked fine with the old inputs_for function that was moved to PhoenixHTMLHelpers. However, this stopped working with Phoenix.Component.inputs_for/1. I can still pass the offset option (or any other option) to make it available in the form data implementation:

~H"""
<.inputs_for
  :let={ff}
  field={@form[:filters]}
  options={[fields: @fields, offset: 5]}
>
  <%!-- ... %>
</.inputs_for>
"""

And, given the offset 5, the protocol implementation produces the correct values in the Form struct:

%Phoenix.HTML.Form{
  id: "flop_filters_5",
  name: "filters[5]",
  index: 5,
  # ...
}

However, Phoenix.Component.inputs_for/1 appears to ignore both the index and the id that the protocol implementation produces. The form structs passed to the inner block always start with index 0 and an according ID (although the name is derived correctly from the form struct returned by the protocol implementation):

%Phoenix.HTML.Form{
  id: "flop_filters_0",
  name: "filters[5]",
  hidden: [{"_persistent_id", "0"}, {:field, :email}],
  params: %{"_persistent_id" => "0"},
  index: 0
}

• Here it initializes the index with 0 instead of the index of the form struct:

  phoenix_live_view/lib/phoenix_component.ex

  Line 2736 in 8ea6b48

  acc = {seen_ids, 0}

• And here it builds a new ID instead of using the one from the form struct:

  phoenix_live_view/lib/phoenix_component.ex

  Line 2747 in 8ea6b48

  form_id =

I noticed that I can initialize the params on the form struct produced by my protocol implementation with a _persistent_id to achieve the previous behavior:

%Phoenix.HTML.Form{
  index: index,
  id: id <> "_" <> index_string,
  name: name <> "[" <> index_string <> "]",
  params: %{"_persistent_id" => index}
  # ...
}

This leads to the correct index being used by inputs_for, but this relies on an internal implementation detail and probably isn’t meant to be used this way.

I don’t know why it was implemented this way, and whether this was an oversight, or what the purpose of the _persistent_id is, or whether I’m doing something wrong. Shouldn't inputs_for retrieve everything it can from the Form struct?

[SteffenDE]

@woylie the persistent_id thing was added by Chris to correctly support reordering (#2570). The way I understand it is that it ensures that even when forms are re-ordered, the fields retain their original ID and therefore morphdom does not recreate them. I think we can change it to start at the given index without problems, but I don't think we can use the ID from the form, as that would introduce changing IDs again. When using inputs_for outside of LiveView, it wouldn't be a problem, so maybe there should be a way to opt out of _persistent_id?

cc @chrismccord

[woylie]

Starting at the given index would solve my use case.

When using inputs_for outside of LiveView, it wouldn't be a problem, so maybe there should be a way to opt out of _persistent_id?

Even within LiveView, reordering inputs isn't relevant for most filter forms. Neither is the tracking of unused fields (this was commented on here). Usually, we prefer to keep the filter parameters as query parameters in the URL. The addition of _persistent_id and _unused parameters leads to unnecessarily long URLs without any benefit. We can remove those parameters in handle_event, but it would be nice to be able to opt out of both indeed.

[SteffenDE]

@woylie I opened #3677 to opt out of the persistent_id generation. I did not change it to use the forms' indexes, because I'm not sure about the consequences. Let me know if that works for you :)

[woylie]

@SteffenDE My test unskipped in https://github.com/woylie/flop_phoenix/pull/430/files passes again with this change, so this appears to resolve the issue. Thank you!