Repository navigation
Experiment: ValidationMode as a strategy class - #107
Closed
KamilSztandur wants to merge 3 commits into
Closed
KamilSztandur wants to merge 3 commits into
KamilSztandur wants to merge 3 commits into
Conversation
A common ask: no error while the user types an email for the first time, validate when they leave the field, and from then on validate every keystroke so the error disappears as soon as the value is fixed. Neither onUnfocus nor onUserInteraction does this on its own. ValidationMode.afterFirstUnfocus is the onUnfocus row of the gate until the field is first left after an edit, and the onUserInteraction row from then on. The field remembers that first unfocus in one bit, set by the event and cleared only by reset(). The gate still reads no status. validate() from a submit button does not count as the first unfocus, and leaving a field the user never edited does not either. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
With four modes the segmented button no longer fits a phone, and
Flutter broke the labels mid-word ("afterFir / stUnfoc / us"). It
already did that to onUserInteraction with three. The row now keeps
its full width where it fits and scrolls horizontally where it does
not, in both copies of the demo.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
What Albert's proposal on #103 would cost, built on top of the fourth mode so the two can be compared. ValidationMode becomes a final class with the four modes as constants and ValidationMode.custom for a mode of your own. A strategy sees a ValidationContext: the event and whether the user has left the field since editing it, never the status or the errors. The untouched-field rule stays in the field, outside any strategy. ValidationEvent becomes public API. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
KamilSztandur
force-pushed
the
after-first-unfocus
branch
from
October 24, 2026 12:34
df3d958 to
acc6e4b
Compare
Collaborator
Author
|
Folded into #103, as decided: the fourth mode and the class with custom() ship together. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this is
A sizing exercise, not a proposal to merge. It builds the idea from the comment on #103 (
ValidationModeas a strategy, open for users' own modes) on top of the fourth mode, so the diff shows exactly what the idea adds beyond the enum.What changes
ValidationModeis afinal classwith the four modes as constants,valuesandnamekept, andValidationMode.custom(name, fn)for a mode of your own.ValidationStrategy.validatesOn(ValidationContext). The context carries the event and whether the user has left the field since editing it. It carries no status and no errors on purpose: both are erased by every edit and by a debounced round, so a strategy reading them would disarm itself as the user starts fixing the value.ValidationEventandValidationContextbecome public API. Both were@internal.setValidationMode, comparisons. Exhaustiveswitchover the modes needs a wildcard, the same break the fourth enum value already causes.Size
lib/)Not done here: the skill, the README table, the FAQ, and the equality story for custom modes (two
customcalls are never equal, so a user who recreates one inbuilddrops the round in flight; the doc says "keep one instance" and leaves it there).Why the enum still wins
The code is small. The cost is what becomes a promise: the event model and the context are frozen as public API, and every future bit (a submit flag, for example) is a compatibility decision. Going from the enum to this class later is as source-compatible as doing it now, so keeping the enum closes no doors.
🤖 Generated with Claude Code