A field has an editing policy
Typed components supply parsing, formatting, labels and validation behavior. A visible draft is not always an accepted value. A rejected edit remains available for correction while Data retains the previous accepted value.
Start with Number editing, then Required values and length. The ordinary HTML input used in the early lessons is not evidence that every native control has the same policy as a typed Gramlot editor.
Test both failure and recovery
A useful validation exercise checks a valid value, a rejected value, an empty draft and a correction. Inspect Data after every step. Derived values should be explained using accepted Data, not the text that happens to be visible in the editor.
The Validation rules and callbacks example adds transformations, warning behavior and callback checks. Client-side checks help the interaction; the receiving service must still validate inputs according to its own rules.
Your turn
Try it yourself
- Open Required values and length. Enter an accepted value, then violate a displayed length constraint.
- Use the gallery inspector to compare the visible draft with Data.
- Correct the value and confirm that acceptance resumes. Repeat with an empty required field.
Check your understanding
Why can a calculation still show the previous result while a field displays a rejected draft?
Show the answer and expected result
The calculation reads accepted Data. The invalid text is an editing draft and has not replaced that value. After a valid correction, the accepted value changes and reactive dependants can update.