Writing validation logic only once: how to get ALL passed and failed form validations to client in realtime

[coen.bakker]

I can’t quite figure out whether this is or isn’t possible with Phoenix:

WHAT I’M MAKING
A user registration form in which the user sees, underneath each input field and at all time, the list of field validations that apply to that field. As the user interacts with the form, the list items should, in real time, give some sort of visual cue (e.g. green check mark) to indicate whether the validation has passed or not.

REQUIREMENT
I am trying to make this work without having to write the validation logic in multiple places. I could write a client side, Javascript solution, but then I would end up writing the validation logic twice, for example.

I thought it would be a matter of getting the info about the errors and validations – including the :message info that can optionally be provided when dealing with changeset validation functions – from the server to the client on page load and each time the form is changed by the user.

However, errors are only added to a changeset if there isn’t an error for that field yet. So you don’t get a list of all errors for a field in the changeset as it returns from the server.

Also, validations/1 returns information about all the validations of each field (except required), which is great, but it does not return the messages that you (as the programmer) can add to the changeset validation functions.

Am I missing something, or is writing the validation logic twice the way to go?

[mindok]

Have you inspected your Changeset in iex (or IO.inspect from you form change event) to confirm that you have all the errors you expect?
Have you inspected the raw html to see if errors make it to the browser, but are hidden?

From the looks of things, there is smart handling around form errors in LiveView - see Form bindings — Phoenix LiveView v0.17.11

Take a look in you app.css and search for phx-no-feedback - you should see a class that hides the feedback if the field has not yet been touched.

[coen.bakker]

Let me walk through the %Ecto.changeset{} and validations/1 data that is being passed around in my app.

To start, this here is what the registration form could look like. In this example only the password field has all requirements listed. Those requirements will change, by the way, but just to give a better idea of what UI I am referring to.

At page load I get this data:

#Ecto.Changeset<
  action: nil,
  changes: %{},
  errors: [
    password: {"can't be blank", [validation: :required]},
    email: {"can't be blank", [validation: :required]},
    username: {"can't be blank", [validation: :required]}
  ],
  data: #TodayForum.Accounts.User<>,
  valid?: false
>

# validations/1
[
  password: {:format, ~r/[!?@#$%^&*_0-9]/},
  password: {:format, ~r/[A-Z]/},
  password: {:format, ~r/[a-z]/},
  password: {:length, [min: 12, max: 72]},
  email: {:unsafe_unique, [fields: [:email]]},
  email: {:length, [max: 160]},
  email: {:format, ~r/^[^\s]+@[^\s]+$/}
]

The errors and validations here are indeed correct, but there are two things missing.

1. The errors of the other validation requirements that are not met.

For example, at page load password requires at least one capital letter requirement is also not met, but that error is not present in the changeset. I understand that this is per design, but in my use case I require all errors to show.

2. The :message data that has been bound to the changeset.

So for example here:

  defp validate_password(changeset, opts) do
    changeset
    |> validate_required([:password])
    |> validate_length(:password, min: 12, max: 72)
    |> validate_format(:password, ~r/[a-z]/, message: "at least one lower case character") # HERE
    |> validate_format(:password, ~r/[A-Z]/, message: "at least one upper case character") # HERE
    |> validate_format(:password, ~r/[!?@#$%^&*_0-9]/, message: "at least one digit or punctuation character") # HERE
    |> maybe_hash_password(opts)
  end

If I enter an invalid password, like:

I get the following data:

#Ecto.Changeset<
  action: nil,
  changes: %{password: "**redacted**"},
  errors: [
    password: {"at least one digit or punctuation character",
     [validation: :format]},
    password: {"at least one upper case character", [validation: :format]},
    password: {"should be at least %{count} character(s)",
     [count: 12, validation: :length, kind: :min, type: :string]},
    email: {"can't be blank", [validation: :required]},
    username: {"can't be blank", [validation: :required]}
  ],
  data: #TodayForum.Accounts.User<>,
  valid?: false
>

# validations/1
[
  password: {:format, ~r/[!?@#$%^&*_0-9]/},
  password: {:format, ~r/[A-Z]/},
  password: {:format, ~r/[a-z]/},
  password: {:length, [min: 12, max: 72]},
  email: {:unsafe_unique, [fields: [:email]]},
  email: {:length, [max: 160]},
  email: {:format, ~r/^[^\s]+@[^\s]+$/}
]

So for the password I get the right errors.

So here is the problem. I want to dynamically create the list of requirements underneath the password field. And dynamically update the styling of these list items depending on whether these requirements are passed or not. With the current changeset and validations info I cannot get it done. Because I need all the errors and all the validations (including the messages) to be sent to the client at page load and any change to the form.

I could only show the list of requirements after the first form change by the user. This eliminates the need for all errors to be sent to the client on page load. That’s fine. But then I still need to validation messages to be passed to the client.

[LostKobrakai]

I think the mismatch here is that you’re trying to build a “list of requirements” from error messages. Error messages are not meant to be requirements. I’d suggest building the shown list only from the validations, have a mapping from validation to requirement. Add the checkmark based on if there’s an error present for the validation or not.

validate_required data is documented (on the validations/1 function) to be part of changeset.required list rather than changeset.validations.

[coen.bakker]

Maybe I haven’t been clear about that, but it was indeed my idea to build the list of requirements from the validations and use the error messages to mark a requirement as passed or not.

To get the :message info (or in general, the requirement statement strings) to the client on each form change, I guess I could use traverse_validations(changeset, msg_func). It’s documented here: Ecto.Changeset — Ecto v3.11.1.

@LostKobrakai

validate_required data is documented (on the validations/1 function) to be part of changeset.required list rather than changeset.validations.

And thanks for this line. I had seen changeset.required in the docs ([here] (Ecto.Changeset — Ecto v3.11.1)) but expected that that key would then show up in the %Ecto.Changeset{} struct as a key, which it doesn’t. But now I’ve tried to simply IO.inspect changeset.required the required fields are indeed logged.

[:password, :email, :username]

(Still confuses me why it doesn’t show in the struct, tbh.)

[eahanson]

I wonder if you could write a custom validator for each field that is a composite of the individual validadora for that field? You might be able to provide enough metadata in the validation response to build the UI you are considering.

https://hexdocs.pm/ecto/Ecto.Changeset.html#validate_change/4

[coen.bakker]

That makes sense to me. I’ll give that a try, actually.

Edit. Got it to work with traverse_validations. After I clean up the code, I’ll post it.

[dodo]

FYI you can use IO.inspect(changeset, structs: false) to disable the inspect protocol of structs and print everything.

[coen.bakker]

@coen.bakker

However, errors are only added to a changeset if there isn’t an error for that field yet. So you don’t get a list of all errors for a field in the changeset as it returns from the server.

To avoid confusion for future readers that are still learning Phoenix. I made a wrong judgement here. I get the impression max one error per field would be included in the changeset, back when I had only two requirements on my password: password required and min length. Seemed like it showed one or the other and I thought I read something in the docs that confirmed my suspicion. But I was wrong, as you can also see from the IO.inspect blocks in this thread.