Testing LiveComponent with JS Hook

I believe you would need to use something like Playwright to test the JS. But your code shouldn’t be getting that error IMO. The Elixir side of the code should be picking up your category_id since it doesn’t really care about the JS implementation.

It looks like the error is suggesting that the category_id field expects a list [], which is strange. Did you create the category_id field as an :array in your migration? I believe that a foreign key should be represented like this in your migration:

add :category_id, references(:categories, on_delete: :delete_all), null: false

If you don’t have this, you could create a new migration, or just edit the existing migration and run mix ecto.reset (which will completely reset the database for the project, be ye warned).

@arcanemachine is right that you wouldn’t be seeing an error here due to JS. If you could share your setup code that would help give more insight but I’m guessing you have @multiple set to true and therefore the attribute should be set like: name="category_id[]" in order to capture the multiple selections. So all you have to do is change your setup attrs to:

  @create_attrs %{
    category_id: ["123"],
    title: "some title"
  }

which is totally legit assuming it’s a multiple select.

EDIT: my raw HTML in this area may be skrewed a bit from working with frameworks for so long as apparently you don’t need to do name="name[]" for a multi-select but regardless, if using a %Form{} or changeset-backed form in Phoenix, they will come through as an Elixir list regardless.

That’s right. form/3 mimics what the user is supposed to be able to do on the form, so you can’t select an option that doesn’t exist yet.

However, you can easily sidestep this limitation by passing some values in render_submit/2 directly.

@arcanemachine here are the migration:

    create table(:posts, primary_key: false) do
      add :id, :binary_id, primary_key: true
      add :title, :string
      add :category_id, references(:categories, type: :binary_id)
      timestamps()
    end

and the schema:

  schema "posts" do
    field :title, :string
    belongs_to :category, Core.Category
    timestamps()
  end

@sodapopcan @multiple is set to false here (it’s the default), so the rendered <select> name is post[category_id].

I tried changing my <select> by adding a couple of <option>s (everything else is the same):

            <select
              class={["combo-box", @class]}
              multiple={@multiple}
              name={@name}
              required={@required}
              {@rest}
            >
              <option value="test1">test1 label</option>
              <option value="test2">test2 label</option>
              <option :for={{value, label} <- @value} selected value={value}><%= label %></option>
            </select>

And I’m getting:

** (ArgumentError) value for select "post[category_id]" must be one of ["test1", "test2"], got: "123"

I also tried with the default Phoenix select component and I’m getting the same error.

So it’s definitely “reading” the available options and “validating” with them (or I’m missing something )

@trisolaran do you mind being a little more specific?
I tried with the following

      assert view
             |> form("#post-form", post: @create_attrs)
             |> render_submit(%{"post" => %{"category_id" => ["123"]}})

Plus a lot of other variations like using atoms for keys, writing "post[category_id]", not using lists…
I always get the same error.

Move category_id from form to render_submit. This should work:

assert view
             |> form("#post-form", post: %{title: "some title"})
             |> render_submit(%{post: %{category_id: ["123"]}})

You were getting the same error because you were still passing category_id in form

That was it! Thank you
Another possible solution that came to mind and I’ll test: adding “static” select options via assigns, so that I can go back to using @create_attrs and avoid “injecting” arbitrary values with render_submit.

Ah sorry, your initial error confused me as I read it as you were getting a type-mismatch. I did some tests but not with an empty <select> because I thought it was getting some default values, even though you clearly said it was the JS that populates it. D’oh.

I knew you could pass form data to it but never knew that’s why. TIL!