Proposal: Add Dirty/Pristine/Touched state to ValidationBehavior for better form-level UX

[matt-goldman]

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 Entry or Editor Text, 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.

ValidationBehavior exposes IsValid as a bindable property. This already enables scenarios beyond the control itself, e.g.:

• Showing a form-level banner: “Form contains errors”
• Disabling a Submit button until all fields are valid
• Showing helper text only after the user interacts with a field
• Highlighting the first invalid field when attempting to submit
• Suppressing warnings until the user has actually touched a field

One workaround for this at the moment is using validation flags - you could, for example, set ValidateOnUnfocused and 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 interacts
• Any form-level binding that looks at IsValid will behave as though the user has already made a mistake
• There is no way to distinguish "this is invalid because the user interacted" from "this is invalid because it hasn’t been touched yet"

This 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:

• Pristine (never touched)
• Touched (received and lost focus)
• Dirty (value changed)

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:

• Add optional tracking of field-interaction state
• Expose this via new bindable read-only properties:

public bool IsTouched { get; }
public bool IsDirty { get; }
public bool IsPristine => !IsTouched && !IsDirty;

This would allow:

• IsValid && IsDirty to control banners or disable submission
• IsTouched && !IsValid to show inline helper messages
• Validation summaries that trigger only after interaction
• Better accessibility cues

We would probably want to update the flags to accommodate this as well, or maybe add a ValidatePristine boolean property instead with a sensible default.

Backwards compatibility

• Existing apps would see no change in behaviour
• No styling changes are required
• No existing VisualStates need to change
• Apps that don’t use these new properties don’t need to do anything

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:

• error messages
• validation triggers
• validity state

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!