Testing LiveComponent with JS Hook

Phoenix Forum Questions / Help
, , ,
1

I need to test that I can create a post having one category (chosen from an async loaded list) on my admin site.

I have a LiveComponent for a select which uses Tom Select JS with a phx-hook like this:

    ~H"""
    <.field_wrapper errors={@errors} name={@name} class={@wrapper_class}>
      <div
        id={"#{@id}"}
        phx-hook="ComboBox"
      >
        <div id={"#{@id}_wrapper"} phx-update="ignore">
          <.field_label required={@required} for={@id} class={@label_class}>
            <%= @label %>
          </.field_label>
          <div class="combo-box-wrapper">
            <select
              class={["combo-box", @class]}
              multiple={@multiple}
              name={@name}
              required={@required}
              {@rest}
            >
              <option :for={{value, label} <- @value} selected value={value}><%= label %></option>
            </select>
          </div>
        </div>
      </div>
    </.field_wrapper>

Here’s the JS Hook:

Hooks.ComboBox = {
  mounted() {
    this.init(this.el)
  },
  init: async function (el) {
    const settings = {
      preload: 'focus',
      load: (query, callback) => {
        const params = {query: query}
        this.pushEventTo(el, 'fetch_association', params, (data) => callback(data.results))
       }
     }

    new TomSelect(el.querySelector('select.combo-box'), settings)
  },
}

The <option>s for the <select> are loaded when the input is focused.
Before focusing, the select only has the options which are already associated to the post (which are empty in tests).

My test:

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

  ...

    test "saves new post", %{conn: conn} do
      {:ok, view, _html} = live(conn, ~p"/posts/new")

      assert view
             |> form("#post-form", post: @create_attrs)
             |> render_submit()

      assert_patch(view, ~p"/posts")
    end

I’m getting this error:

value for select "post[category_id]" must be one of [], got: "123"

I’m guessing that this is because the <option> list is empty and Phoenix checks for a list of possible values?

How can I test this since the <option>s are filled by the JS hook? I see that render_hook exists, but of course it doesn’t run the JS part.
I guess I can also avoid testing the JS hook itself by injecting a list of <option>s for this test’s purpose, but I’m not sure how.

Thank you!

2

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).

1 Like
3

@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.

4

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.

1 Like
5

@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 :slight_smile: )

6

@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.

7

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

8

That was it! Thank you :slight_smile:
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.

9

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!

1 Like