Proposal: Add Dirty/Pristine/Touched state to ValidationBehavior for better form-level UX #2996
matt-goldman
started this conversation in
New Feature Discussions
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi team (and community),
I’d like to raise a small but meaningful enhancement proposal for
ValidationBehavior.Current validation only models Valid/Invalid, but a core UX paradigm is Dirty/Pristine/Touched.
This allows much better UX by not immediately assaulting users with error state visuals for things they haven't touched. I think this likely hasn't been an issue because samples usually target styling properties of
EntryorEditorText, so users don't see it until they type something anyway. I've been working on a custom control library that integrates with the Community Toolkit so this showed up for me straight away when I targeted the border.However, even with the default controls this can still be an issue for other users.
ValidationBehaviorexposesIsValidas a bindable property. This already enables scenarios beyond the control itself, e.g.:One workaround for this at the moment is using validation flags - you could, for example, set
ValidateOnUnfocusedand this would sidestep the problem. But this doesn't provide the reactive, real-time validation UX many users expect.If you want to use
ValidateOnInputChange, which I suspect most people do (which is supported by the samples), any validator where empty = invalid (email, min length, numeric range etc), this means:IsValid= false before the user interactsIsValidwill behave as though the user has already made a mistakeThis is a common UX problem when building forms.
Example scenario
A form that shows this “Form contains errors” will show that message immediately on load, even when the user hasn't interacted with any fields.
Or, a much more common example would be disabling a submit button when forms contain errors. Granted, in this scenario, the button would be disabled when the user has not entered anything. So that's a bad example, but I think it illustrates the point all the same.
Another bad example (but I've seen it so it's real) - showing users password requirements if they try to submit a password that doesn't meet them (they should really show this first, but again, demonstrates the point).
Established patterns
Most frameworks with built-in validation expose three concepts:
These allow the app to delay visual or form-level validation until the user interacts.
Proposed enhancement
Without suggesting any breaking changes, the core idea is:
This would allow:
IsValid && IsDirtyto control banners or disable submissionIsTouched && !IsValidto show inline helper messagesWe would probably want to update the flags to accommodate this as well, or maybe add a
ValidatePristineboolean property instead with a sensible default.Backwards compatibility
This enhancement simply gives developers the ability to distinguish between “invalid because untouched” and “invalid because user input is incorrect”.
Justification
While consumers can implement dirty/pristine tracking manually, doing so for every Entry/Editor defeats the purpose of having a reusable validation abstraction. ValidationBehavior already centralises:
Feedback
I'm happy to draft the proposed API changes and open a PR, but before I do I'd like to see what others think.
I'd love to know whether others agree this should be in here, and if it supports better form workflows and UX. And if there are other patterns that need to be considered/included as well.
Happy to provide a small example implementation sketch if helpful.
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions