Generating clientside validation on inputs from ecto schemas/changesets

Ecto already does that: Ecto.Changeset — Ecto v3.13.4

Those attributes have footguns as well. E.g. if you have a required attribute on an input hidden by some UI like tabs or disclosure the form simply won’t submit without any feedback to the users what’s wrong.

Interesting problem. I wonder if the sensible approach to that would be in css selectors.

IE:

body:has(input:invalid:required) .global-validation-indicator {
  display: block;
}

Also how common is this that you would have hidden forms like this?

I haven’t really kept up with the state of native client side validations. This is just one I was remembering, but at least in early days there were more than just this one issue with them. And even when they work the other question is how well they compose with additional validations coming either also from the client or from the server. That doesn’t mean you should never use them, but I was trying to make a point that there are reasons for not having them as well.

The pragmatic approach is to do validation on the server, although I prefer client validation, I think the harder part is actually generalizing this, since you have a lot of different browsers. That being said, I do not believe there is any technical blockers and the question might just be about maintenance and support.

Yes, check out Phoenix.HTML.Form.input_validations/2

I’ve seen a good amount of websites deal with this simply by putting an error at the top of the form without it being attached to any input field. Some of them also auto-scrolled you to the top of the form and did a short blinking effect on the error message as well.

Not to invalidate your point, I am pointing out that it’s an old problem and enough people shrugged it off with “Well, not every error belongs to a singular field. Some errors introduce a holistic form-wide error so let’s show the users that.”.