Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Omit meaningless markup from hidden input in core components #5700

Conversation

bopm
Copy link

@bopm bopm commented Jan 19, 2024

Motivation

The current version of core components given

<.input type="hidden" field={@form[:user_id]} value={@current_user.id} />

produces next markup

<div phx-feedback-for="message[user_id]" data-phx-id="..." class="phx-no-feedback">
  <label for="message_user_id" class="block text-sm font-semibold leading-6 text-zinc-800" data-phx-id="..."></label>
  <input type="hidden" name="message[user_id]" id="message_user_id" value="2" class="mt-2 block w-full rounded-lg text-zinc-900 focus:ring-0 sm:text-sm sm:leading-6 phx-no-feedback:border-zinc-300 phx-no-feedback:focus:border-zinc-400 border-zinc-300 focus:border-zinc-400">
</div>

Most of that is completely meaningless for hidden fields.

Change

After implementing these changes, it'll generate next markup:

<input type="hidden" name="message[user_id]" id="message_user_id" value="2" data-phx-id="...">

name={@name}
id={@id}
value={Phoenix.HTML.Form.normalize_value(@type, @value)}
/>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably want a {@rest} in here to capture any additional provided attributes.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rest consists of things that should not be in hidden input as well. At least to my understanding. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/hidden

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Passing something like form can still be relevant for hidden inputs, therefore rest should be included in my opinion.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added.

@josevalim
Copy link
Member

For what is worth, I don’t think we should support :hidden through <.input. Instead, I would just write the input directly.

@josevalim
Copy link
Member

@josevalim
Copy link
Member

We should remove radio as well to solve #5506 .

@bopm
Copy link
Author

bopm commented Jan 29, 2024

For what is worth, I don’t think we should support :hidden through <.input. Instead, I would just write the input directly.

I tried it too, leading to an unsafe input error. I am AFK to reproduce that error exactly, but it is something like that.

@bopm
Copy link
Author

bopm commented Feb 6, 2024

Yep, the exact error is

Phoenix.HTML.Safe not implemented for %Phoenix.HTML.FormField

@SteffenDE
Copy link
Contributor

@bopm you will have to do something like this when using <input> directly:

<input type="hidden" id={@form[:field].id} name={@form[:field].name} value={@form[:field}.value} />

You cannot pass the form field to a plain input tag, that's where the error comes from.

@bopm
Copy link
Author

bopm commented Feb 6, 2024

@SteffenDE That works, but do I understand correctly that this way I am losing things like Phoenix.HTML.Form.normalize_value?

@SteffenDE
Copy link
Contributor

That's right, but normalize_value does nothing for "hidden" inputs anyway. As this PR is only about what is generated in new applications, you can of course keep the "hidden" case for the <.input> component in your app. That's what I do as well, as I see a benefit in not always writing out the attributes.

@bopm
Copy link
Author

bopm commented Feb 6, 2024

That makes sense too, my other concern is that this general approach that @josevalim is offering will push developers to remember that some field types require different notation than others. For me, don't make me think feels like a better approach, as Phoenix is already complex enough, but I am unsure if I am getting it all right.

@josevalim
Copy link
Member

I squeezed it all into a one liner, so maybe it is more amenable for merging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants