Missing Email field?

[rakso-startkoden]

The documentation https://hexdocs.pm/backpex/what-is-a-field.html#configuration mentions a Email field, but it seems to not actually exist. I need it for my current project so I will implement it myself if its missing. Would you be interested in a PR with this?

Thank you!

[Flo0807]

Hey, good catch! I removed the field from the docs in #420. I would be interested in a PR. What features do you have in mind for an email field?

[rakso-startkoden]

I guess the main things are to have the input element use the correct type and then the option of having the value rendered using a anchor with href="mailto.

But as I'm writing I realize this is maybe something that is more effectively done by adding something more generalized as an option to the Text field where you can override the type of the input. This together with a separate generalized option to have any value rendered as a link would allow developers to choose themselves if they want clicking the email to do the mailto thing, or if they would like it to link for example a page showing all the emails sent to that email.

Some suggested code to illustrate what I'm rambling about

  def fields do
    [
      contact_email1: %{
        module: Backpex.Fields.Text,
        searchable: true,
        label: "Contact email"
        input_type: "email",
        value_link_fun: fn value -> ~p"/sent_emails?contact_email=#{value}" end 
      },
      contact_email2: %{
        module: Backpex.Fields.Text,
        searchable: true,
        label: "Contact email"
        input_type: "email",
        value_link_fun: fn value -> "mailto:#{value}" end 
      },
...

But I understand if you think this is too messy and its not really a issue to create custom fields. But I do think a Email field with some common defaults such as the mailto href etc, could be useful.

[Flo0807]

In my opinion, we should focus on creating additional fields rather than complicating existing fields. If there is a need for email values, let's create a new field for that specific use case.

We once tried to merge Text with Textarea, but it did not work out well. So I suggest sticking to a separate Backpex.Fields.Email field is a good idea.

its not really a issue to create custom fields

If you have a really specific use case, I recommend creating a custom field in your application, but an email field is certainly not and could be useful for other applications as well. So I would love to see a pull request from you.

But I do think a Email field with some common defaults such as the mailto href etc, could be useful.

I agree 🤝

[SebastianMueller87]

You can already overwrite how the value is displayed by using render_value (index & show).

There are already some functions to configure how to render a field in a form, see here.

The task would be to add a an option to the change the type from text to any other type. This could also be confusing because you could also add “button“ as type and this would lead to confusing behaviour. So in my opinion it would be better to have a separate email field. ;)

EDIT: You need to use render as key, not render_value to override it at the moment. Thanks for the hint @Flo0807

[rakso-startkoden]

Thanks for the feedback and I agree, adding email field makes sense. On vacation atm, but will create a PR for it next week when I'm back.