Design a better validation experience for MVC

[danroth27]

#8573 (comment) covers the problem statement for this issue

---

Bootstrap 5 is removing it's dependency on jQuery: twbs/bootstrap#23586

This issue tracks investigating what removing jQuery as a dependency from ASP.NET Core would take.

We're going to split this work into two phases:

1. Design the new JS library to replace jquery-validation-unobstrusive
2. Implement the above
3. HTMLHelper default css class names #17412

[mkArtakMSFT]

@ryanbrandenburg can you please investigate and come up with some cost for this work? Thanks!

[mkArtakMSFT]

@danroth27 seems we rely on jQuery for our validation too, it's not just transitive because of Bootstrap dependency.

[danroth27]

@mkArtakMSFT Right, the main work item tracked by this issue is investigating what it would take to remove the jQuery dependency from our validation support.

[danroth27]

Given that our current validation support is built on jQuery validation, the way I would think about this issue is to take a fresh look at what our client validation support should look like. Is there a different validation library that we should consider using? Etc.

[ryanbrandenburg]

The one option that seems to be most popular (and standards compliant) would be using the built-in HTML5 form validation. The problem there is that it would only work for client-side validation. As far as I can tell HTML5 form validation doesn't solve any server-side validation problems, and even if it did it would require a lot of changes to DataAnnotations. HTML5 also isn't supported on older browsers (IE9 was the example I found).

In my opinion it's not worth the work that would be required to remove our dependencies here in the absence of a more unified vision about what value we can produce from re-working DataAnnotations.

[daikoz]

There is no standard way to change their look and feel with CSS.
Of course, I'm agree. But if you check validitystate and update le class name in javascript on client side, it is a workaround.

They depend on the browser locale, which means that you can have a page in one language but an error message displayed in another language.
If .net keep the data-* for message and manage it on client side to display it. It solve the issue.

[sanamhub]

This issue is still unplanned?! wow..

[jerriep]

@sanamhub I doubt this will ever happen. It seems obvious that Blazor is the new flavour-of-the-month UI framework at MS, and it has a validation story built-in. I doubt you can expect any enhancements on the MVC and Razor Pages side going forward - unless it happens as a byproduct of their work on Blazor.

So, I suggest you look at alternatives. That's what I did since my comment on this issue more than 3 years ago.

[lonix1]

@jerriep What alternative are you using?

[jerriep]

@lonix1 I am using React for my frontends now, primarily because of the massive ecosystem of libraries and components. If you want to stay in the .NET world, I suppose Blazor is the proper alternative. If you are locked into using MVC/Razor Pages, then you should probably look at something like https://github.com/haacked/aspnet-client-validation, which I mentioned earlier in this thread - it seems well-maintained.

[sanamhub]

cc @danroth27 @MackinnonBuck

[dahlbyk]

It seems reasonable to continue iterating on https://github.com/haacked/aspnet-client-validation rather than reinvent a first-party equivalent. We still haven't shipped 1.0, so breaking API feedback is welcome. Need a nonzero testing story, too. Sponsors? 😁

#34777 was a great solution to #17412 (other than deleting public members that should be marked [Obsolete] instead). The documentation for the new properties should include a warning like:

Changing this value is incompatible with jQuery Unobtrusive Validation 4.x and lower.

...with a link to docs that can be updated to reflect the current state of the art. That may eventually be "it Just Works™️ with jUV 5.x or aspnet-client-validation" but in the meantime it can enumerate known limitations/options.

I don't think anyone is surprised that updating jUV isn't a top priority for the team, but waiting on a perfect solution has thus far meant there's no solution (except reflection). A well-documented optional configuration seems like a great first step that can be mostly community-driven.