Semantics of the <.input type="checkbox"> in core components

The component is mean to work with the semantics of Phoenix.HTML.Form data. It supports more datatype as HTML forms do, including boolean true/false, which those checkboxes handle.

If you’re not using a Phoenix.HTML.Form form you can still construct the input on your own instead of using the core component: <input … />. Nobody requires you to use <.input … />.

Also the core_components are part of your codebase. Feel free to customize them to your requirements. What phoenix generates is a baseline, which you can leave as is, customize or even remove completely.

This design is made to work for the basic use of checkboxes, to toggle a single value on/off.

The code creates a hidden input with a false value for the field name, so that submitting the form results in a “false” value if the user didn’t check the option, and “true” if they did.

Having a text value is useful in the multiple-checkbox pattern, where the user can choose from more than 1 option for a particular field name. In that case you can roll your own input component that loops through the various options, sets the value for each option, and does its own logic for setting the correct “checked” input.

See Handling multiple checkboxes (MDN)

Of course… but isn’t the point of core components to being “core”? We use Phoenix.HTML.Form on some parts of our app, and not in some other parts, but we still want harmonious UI…

And the <.input> components from core_components are absolutely not tied to Phoenix.Html.Form. Do you imply that we should create another set of core_components when not using Phoenix.Html.Form? I’m pretty sure that you do not.

Also the core_components are part of your codebase. Feel free to customize them to your requirements. What phoenix generates is a baseline, which you can leave as is, customize or even remove completely.

Yup.

The discussion I was looking to have is about the DX of the core components. Developers know html, and having something that feel like html, that as the same naming as html, but that is not behaving like html is misleading. And I think it may be improved, we are not looking for escape hatches

I kinda agree on this one. But I could still wanting to use the <.input type="checkbox" /> in this case I guess. Especially if I have customized my core input[type=“checked”] component with custom complex styling (since that’s the selling point for tailwind reusibility).

The important bit here is that core_components as they’re generated are to support the markup of the phoenix generators. They’re build to be flexible to not break down as soon as you go beyond that, but they’re not build to support any and all usecases you might have for inputs. Your requirements seem to go beyond what is there, so you can decide if you extend what is there or if you add some additional components. The file is in your codebase so feel free change it however you need.

E.g. this blog post goes and adds an multi checkbox input:

It won’t work for the default component, but a similar one could be:

  def input(%{type: "multi-checkbox", labelled_options: labelled_options} = assigns) when is_list(labelled_options) do
    ~H"""
    <div phx-feedback-for={@name}>
      <input type="hidden" name={@name} value="none" /> <=== optional depending you your use case?
      <%= for {option, label} <- labelled_options do %>
        <label class="flex items-center gap-4 text-sm leading-6 text-zinc-600">
          <input
            type="checkbox"
            id={"#{@id}-#{option}"}
            name={@name}
            value={option}
            checked={@value == option}
            class="rounded border-zinc-300 text-zinc-900 focus:ring-0"
            {@rest}
          />
          <%= label %>
        </label>
      <% end %>
      <.error :for={msg <- @errors}><%= msg %></.error>
    </div>
    """
  end

(Not tested, just off the top of my head)

I think the issue here is there <.input> is closer to the API of Phoenix.HTML.Form like the old checkbox(f, field, …) than it is to <input>. The component is not meant to be shallow wrapper for <input>.

Thank you both, but as i said, we are not looking for escape hatches We know how to write phoenix components, and we are already not afraid to add our own or even modify our core components modules.

The important bit here is that core_components as they’re generated are to support the markup of the phoenix generators.

I understand this point of view, but my expectations were a bit wider than that (that’s ok if my expectations are not supported natively, don’t worry :D). We are using the core_components as global components available across all our application to share styling and behaviors. I expect our core components to not bother if the view is generated by phoenix generators or hand crafted.

The thing that triggered my post, was only that I spent some times to understand why my <.input type="checkbox"> was not acting as a <input type="checkbox"> (notice how small the diff is?).

From there, I had to read the core components generated by phoenix to understand the difference of behavior. I know they are part of our app and our maintenance, but still, at first, it’s not “our” code, and it felt like reading an external lib source code. I even compared our core_components with phoenix source code to check if our core components have been modified locally or if it is the intended behavior by the phoenix team, trying to understand the reasons behind those choices.

So – maybe (don’t feel attacked) – there is room for a better DX here (either in documentation, in phoenix generated code, i don’t know).

Once again, not looking for solutions. Just sharing a non optimal experience with phoenix. Having a non optimal experience with phoenix is rare enough that I thought that I could share it in case some things could be improved.

that’s all. thanks.

The component is not meant to be shallow wrapper for <input>.

But it has the look and feel of it, that’s my point: it’s misleading!

I’d expect that maintaining both the interface of “a plain input” and the interface of everything phoenix wants on top won’t be that simple. Even more when you expect people updating their code bases from Phoenix.HTML.Form.changeset/3.

Yeah, there could be more signal that the component is higher level. It also includes labels and such. Maybe just form_input could make this less of an issue.