Are closed feature requests ever re-considered?

[DavidThielen]

Hi all;

There's this one feature I would very much like to see added to Blazor. It was closed as "This is not something we plan to do in the near future."

It was closed over 4 years ago.

So... does closed mean it's never going to happen? Or are requests like this revisited at times? Or, after N years, should someone request it again to get it on the radar? And if so, what value is N?

thanks - dave

[danmoseley]

Cc @mkArtakMSFT

[davidfowl]

It's definitely possible but it shouldn't be reopened, a new issue referencing that one would be better. Also, it's a massive change and a potentially breaking one so that's why nobody is eager to implement it. That said, it's important to understand how important it is and what the existing workarounds are today that customers are using to determine if we should go the extra mile and make this change (the usual cost benefit analysis).

[DavidThielen]

I didn't include mkArtakMSFT because I didn't want to be that annoying one going - my ask is soooo important.

So for the same reason, asking a follow-up. Would it be ok if I entered a new issue on this, listing why I think it's worth the effort? (Granted, your effort, not mine.)

Also, I've been programming 40 or so years, and in that time I've worked with a ton of systems. Blazor is one of the cleanest most well thought out systems I've ever used. The architecture/design of it is damn close to perfect.

thanks - dave

[danmoseley]

@DavidThielen you're always welcome to open a new issue (as david suggested).

thanks for the kind words about Blazor. cc @SteveSandersonMS so he sees them also.

[SteveSandersonMS]

Thanks @DavidThielen! Yes, I agree with others that filing a new issue would be reasonable. However for context I'll explain more about the thinking here.

We did design the system to accommodate this at a low level but mainly with the goal of supporting people implementing their own UX flows in code. The core thing is that there's no standard way to represent "some stuff is going on and you may or may not be able to continue without waiting for it, trigger retries, etc.", especially when there could be chains of dependencies like "async rule A influences whether rule B applies" or "evaluating rule X means pinging an API endpoint except if we already did that". I've worked with validation frameworks in the past that have a built-in notion of an "async rule" and it's often sufficient, but when it doesn't happen to line up with your UX goals you still have to reinvent everything from scratch.

My hope is that we provide enough low-level machinery that you can code your own flow, and to an extent that is already possible. For example during OnValidSubmit you can trigger some async logic of your own and update the UI state to reflect this, then after it completes you can insert further messages in to the ValidationMessageStore to represent the outcome if it's a validation failure, and possibly retrigger synchronous validation. The exact combination of steps and how you show progress in the UI is down to you.

I think we'd definitely be open to adding further low-level APIs if they are going to support people coding their own flows, but perhaps less enthusiastic about baking in one specific UX design that we expect everyone to stick to.

[DavidThielen]

@danmoseley @davidfowl @SteveSandersonMS @mkArtakMSFT - first off thank you for very thoughtful replies on this. I'm not going to open a new issue as you all have clearly thought about this in a lot more depth than I have. And to Steve's point, you want a good general solution, not a "let's give Dave what he wants today" quick fix.

But I do want to leave you all with a couple of thoughts around this:

1. I use CustomValidation along with DataAnnotationsValidator because there's no way to programmatically push errors into DataAnnotationsValidator. The combination works but as you look at all this, maybe there should be an expansion to DataAnnotationsValidator to allow different kinds of validation happening in the background.
2. Key to this I think is giving us the ability to:
   1. Kick off an async validation when the user moves from one field to another.
   2. When it goes to submit, give us a way at that point to await any pending async validations we kicked off.
3. I also use ObjectGraphDataAnnotationsValidator in places. Yes it's still in "beta" and clearly abandoned. But it performs it's job in a very clean way. So consider that functionality as you approach all this.
4. And when the user clicks submit, if we need to hit the DB and/or call some services to determine if we're good, tell us how best to do that. The answer may be forget ValidationAttribute for validation that takes time, but give us a clean way to do this.

As for my specific needs:

1. For a upsert of a user, I have to hit the DB to make sure their email is unique (probably the number 1 async validation need out there).
2. For a upsert of the address, I need to hit Azure Map API to convert it to the validated address. And prompt them if Azure gave me multiple matches.
3. For a upsert of a phone number outside of the US I need to hit the Twilio service to get the properly formatted number. (This can take seconds!)

Anyways, keep up the good work and again thanks for listening.

stay healthy - dave