Server validation with a validator component upgrade#37113
Conversation
There was a problem hiding this comment.
Pull request overview
Updates the “Server validation with a validator component” guidance in validation.md to introduce a .NET 10+ flow that uses a Minimal API-based validation endpoint and splits the content into versioned blocks.
Changes:
- Adds a new
>= aspnetcore-10.0section demonstrating server validation via a Minimal API and a client/server validator abstraction. - Reorganizes the existing guidance into
>=8.0/<10.0and<8.0moniker blocks. - Introduces new sample code and updated narrative around client + server validation responsibilities.
|
Hi @guardrex, sorry for not getting to this sooner. I did read through the whole PR but a first general comment is that by using a validated Minimal API endpoint (instead of a MVC controller) I meant using the built-in validation feature we added in .NET 10 that you enable simply by calling That should significantly simplify the examples because you don't need to build and register any custom validators (the |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
@oroztocil ... I confirmed that the server-side built-in validation ( When I removed the "Accommodation" field range (1-100000) DA validation from the BWA's 
If I then correct that to get the built-in validation to pass but break the special check performed in code, it then also throws the 400 with the problem details showing the expected form result ... 
AFAICT, what's on the PR is fine with perhaps a few more code improvements. I also perform a quick test to confirm that a custom validation attribute in the Minimal API works well with the built-in validation. I'm sure it will work fine. Then, I'll add a quick remark (or a short section) to this PR on it. Stand-by a bit longer ... making progress here! 🎉 ... and we might have some decent draft coverage to look at soon. |
|
It works! 🎉 In the Minimal API ... using System.ComponentModel.DataAnnotations;
namespace MinimalApiJwt;
public class CustomValidator : ValidationAttribute
{
protected override ValidationResult IsValid(object? value,
ValidationContext validationContext)
{
if (value is not null)
{
var intValue = (int)value;
if (intValue > 500000)
{
return ValidationResult.Success!;
}
}
return new ValidationResult("Accommodation must be greater than 500000.",
[validationContext.MemberName!]);
}
}In the [CustomValidator]
public int MaximumAccommodation { get; set; }Result when an invalid figure is provided ... 
Correcting the figure, the validation passes ... 
|
|
@oroztocil ... Made a final round of updates to the draft content. I added some remarks (not a section) on custom validation attributes. It's ready for review now. |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 5 comments.
Comments suppressed due to low confidence (1)
aspnetcore/blazor/forms/validation.md:680
- This snippet includes
using Microsoft.AspNetCore.Mvc;but doesn't use MVC types. In a.Clientproject, that using can be misleading and may not compile unless MVC packages are referenced. Remove the unusedusing.
using Microsoft.AspNetCore.Components;
using Microsoft.AspNetCore.Components.Forms;
using Microsoft.AspNetCore.Mvc;
namespace BlazorSample.Client;
|
|
||
| Add an interface for a form validation service to the `.Client` project in the `Starship` folder. The interface is used to register a service for server validation on the server or client validation on the client. | ||
|
|
||
| `Starship/IFormValidator.cs`: |
There was a problem hiding this comment.
Is it necessary to have the IFormValidator and the two implementations? If nothing else, the naming *Validator may confuse people who are accustomed to the DataAnnotationValidator (which is a component they insert into EditForm).
| } | ||
| else | ||
|
|
||
| var request = new HttpRequestMessage(HttpMethod.Post, |
There was a problem hiding this comment.
Why is the Server project delegating to a Minimal API endpoint if it can invoke the custom validation code directly? We could get rid of all the code involvingc IHttpContextAccessor, token passing, JSON de/seralization, and so on.
| builder.Services.AddValidation(); | ||
| ``` | ||
|
|
||
| Built-in validation automatically intercepts the endpoint request and validates the types that the endpoint receives. If the model fails validation, the framework returns a *400 - Bad Request* response with error details without executing the endpoint's code. |
There was a problem hiding this comment.
Probably better to not mix the standard validation pattern with AddValidation and DataAnnotations validation attributes with the custom validation. Or if the intention is exactly to show how the custom validation can be added on top of the built-in one, then call this out explicitly somewhere here.
|
|
||
| namespace BlazorSample.Client; | ||
|
|
||
| public class CustomValidation : ComponentBase |
There was a problem hiding this comment.
Is it necessary to introduce the ClientValidation class that wraps work with the message store?
|
|
||
| :::moniker-end | ||
|
|
||
| ## Server validation with a validator component |
There was a problem hiding this comment.
This example still seems overly complex. I appreciate the work that went into this but I am a big fan of docs that are minimal in showing only what is specific for the scenario being taught and omitting custom infrastructure and ceremonies.
First, can we find a different name for this section? I know there are precedents in the docs but I would move away from calling this "server validation". Maybe "remote validation"? The pattern here is basically what the MVC's Remote validation attribute did, only with more manual plumbing. Also, where is the validator component mentioned in the title? The ClientValidation class is just a wrapper for the message store.
Second, can we reorder the sections in the long Blazor forma validation article so that the docs flow from the most basic/standard/default scenarios to the more advanced/custom ones? For typical Blazor apps the order of complexity is roughly:
- Built-in validation rules using validation attributes and a
DataAnnotationsValidatorinsideEditForm. - Custom validation rules using custom validation attributes or
IValidatableObjectand aDataAnnotationsValidatorinsideEditForm. - Information about
AddValidation. - Custom validation logic using the API of
EditFormandEditContext. - Only then something like this.
Thinking about it more, it might help us to break up this long article into one that cover 1-3 and another covering 5-6.
|
cc: @danroth27 ... You might want to weigh in on this one. This is the section that @oroztocil and I are discussing for updates ... Server validation with a validator component What I have on this PR works 🎉, but the whole section might have outlived your desire to maintain it, falling into the "an advanced scenario for devs to work out on their own" bucket. 😄 BTW @oroztocil ... We're still waiting on getting the P5 PRs merged. Wade and I are on the case, and we'll get the P5 content live ASAP 🏃♂️. I opened Improve section order and possibly split the article ( WRT this section ...
Yes ... I'll update the section heading. 👍
Ok ... easy fix. 👍
I think calling it out makes sense. The dev can decide to drop built-in validation if they're only looking to implement custom remote validation. I'm glad to see both working well together! It's pretty sweet IMO!
Under this paradigm, the Minimal API is part of the use case. There would be several user-facing apps ... BWAs and perhaps other types of apps ... all hitting this other web API app/project for their centralized validation. Also, this is probably the most complicated scenario with the BWA adopting Interactive Auto rendering 😵😄, given that the BWA requires the two-service pattern for server/client rendering. If a dev is only adopting SSR or CSR across their apps, this is an example that they can deconstruct down to a simpler remote validation scenario without the Interactive Auto rendering complexity.
Yes, but it seems like a lot of new-to-.NET/new-to-Blazor/new-to-programming devs are going to be significantly challenged trying to do this on their own. Of course, you could let me know that you feel this whole section's approach isn't welcome any longer for any of several reasons. Do you want to consider dropping the entire section? I leave it up to you and @danroth27 to let me know. 👂 I'll try to get it resolved either way before my OOF period starts on Tuesday. |
|
@oroztocil ... Updates on the last commit ...
The overall paradigm is unchanged ... multiple BWAs and other apps hitting a Minimal API for validation. The Minimal API uses built-in and custom validation. The built-in validation aspect is called out both in the section's lead-in remarks and by an added remark near the Still ready to 💀 the entire section if you and @danroth27 prefer to label this an advanced case for devs to work out on their own. Otherwise tho, please check my 🦖 RexHacks!™ 🦖 for poor coding 🙈 ... but ... what's here seems to at least work 🎉. Let's take up reordering the sections and probably breaking the article into two articles on the other issue that I opened in July if I'm still here 🤞🍀. |
Fixes #36051
Ondřej ... Per your suggestion in #35972, the general idea is to replace the MVC controller with a Minimal API validation, including the unified validation experience.
To simplify the section, the content is versioned into >=10.0, >=8.0/<10.0, and <8.0 blocks. I think we only need to focus on the new guidance in the >=10.0 coverage at the top of the section. I haven't received any complaints (or death threats 💀😨😆) from our readers on our MVC controller-based guidance.
Internal previews