Using Phoenix.HTML.Form for M2M-Relations using a Multiple Select Input in a LiveView

I think the select is supposed to be for @form[:category_ids].

The many_to_many :categories in the schema takes the categories key for itself so you can’t use it.

So would it be best to change the change_article function to populate category_ids?

def change_article(%Article{} = article, attrs \\ %{}) do
   article
   |> Article.changeset(attrs)
   |> Ecto.Changeset.put_change(:category_ids, attrs["category_ids"])
 end

That would make it harder to be re-used in the update and create functions, as I would have to parse the IDs in both of them

def update_article(%Article{} = article, attrs) do
    article
    |> change_article(attrs)
   # put_assoc from list of ids..
    |> Repo.update()
  end

attrs["categories"] there needs to be category_ids, too. list_categories_by_id and put_assoc are doing the work of wiring up the associated data. Read more about it here: Ecto.Changeset — Ecto v3.14.0

Mh yes, but the changeset returned by change_article ends up to build the form using to_form atm:

  defp apply_action(socket, :new, _params) do
    article = %Article{}

    socket
    |> assign(:page_title, "New Article")
    |> assign(:article, article)
    |> assign(:form, to_form(Catalog.change_article(article)))
  end

So category_ids has to be in the changeset (if I’m not missing anything).

But it also might just not work out this way, when m2m relations are involved.

Where would you inject category_ids into fhe form?

When you submit the form, part of the article params will be category_ids. When that goes into the create or update context functions, those will call change_article where it gets passed to list_categories_by_id and the result of that query gets shoved into the changeset by put_assoc.

Ahhh! Now I got it!

<.input
          field={@form[:category_ids]}
          type="select"
          multiple={true}
          options={category_options(@article)}
        />

@form[:category_ids] in this case merely defines the name of the submitted value not the value itself.

The actual submitted value is defined by the options={category_options(@article)} which renders to options.

I was wondering where :category_ids would be populated, as only the changeset with :categories is assigned (as a HTML.Form):

|> assign(:form, to_form(Catalog.change_article(article)))

Thank you very much for clearing things up!

I think the confusion is coming from the relationship between the Phoenix.HTML.Form struct that comes from the to_form function and what you pass to it(in this case %Article{})?

In here Phoenix.HTML.Form — Phoenix.HTML v4.1.1 there’s this snippet:

It is possible to “access” fields which do not exist in the source data structure. A Phoenix.HTML.FormField struct will be dynamically created with some attributes such as name and id populated.

Yes I noticed that it’s possible, but I didn’t understand when and how to make use of it.

The frameworks I used so far, expected to have a form data structure completely defined to render it properly and I treated the changeset as such in my mind.

In Phoenix, if you want to sketch out a form quickly, you can use to_form(%{}, as: "some_name"). You can then put whatever inputs to shape the params however you like.

I’d suggest reframing “article form setting categories” to “article form managing article_categories”, so moving from many to many to has many relationship. Then you can use inputs_for + select for category_id.