Generating clientside validation on inputs from ecto schemas/changesets

[anon9372508]

I’m looking for feedback on my idea of how I can possibly build a solution to creating client side dom validations using a changeset.

Before you say x framework, let me just stop you right here.

The primary focus of this convo I would like to keep to that of just conceptual ideas around the following:

• Create ecto schemas validations like we already do.
• Generate some data that describes these validations and package that along side or in a changeset
• Update the core components input functions to make use of this validation data and generate client side input validations like (required, minlength, pattern ect)

Client-side form validation - Learn web development | MDN

First has anything like this already been tried, done?
Second outside of the fanboyism for liveview/ash/hologaram/vue/svelte/x/y/z whats your take?

Personally I’m kind of shocked to not already see something that sets the required of an input by default even if just as a common pattern.

[LostKobrakai]

@anon9372508

• Create ecto schemas validations like we already do.
• Generate some data that describes these validations and package that along side or in a changeset

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

@anon9372508

Personally I’m kind of shocked to not already see something that sets the required of an input by default even if just as a common pattern.

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.

[anon9372508]

@LostKobrakai

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?

[LostKobrakai]

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.

[Schultzer]

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.

[ibarch]

@anon9372508

First has anything like this already been tried, done?

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

[dimitarvp]

@LostKobrakai

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.

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.”.