Form Validation Patterns
Best practices and patterns for implementing form validation in Fidus, including real-time, async, and cross-field validation.
Validation Principles
1. Validate on Blur, Not on Input
Validate when the user leaves a field (onBlur), not on every keystroke. This prevents showing errors prematurely while the user is still typing.
2. Show Success States
Display a check icon or success indicator when validation passes. This provides positive feedback and confidence.
3. Clear, Actionable Error Messages
Error messages should explain what went wrong and how to fix it. Avoid technical jargon.
4. Preserve User Input
Never clear the field when validation fails. Let users correct their input without retyping everything.
Real-time Validation
Validate input immediately when the user leaves the field (onBlur event).
Async Validation
Validate against a backend API (e.g., checking username availability). Show a loading state during validation.
Try "admin" or "root" to see error state
Cross-field Validation
Validate one field based on the value of another field (e.g., password confirmation).
When to Validate
| Event | Use Case | Example |
|---|---|---|
| onBlur | Real-time validation after user leaves field | Email format, required fields |
| onChange | Character count, formatting | Phone number formatting, max length |
| onSubmit | Form-level validation before submission | Cross-field validation, all required fields |
| Debounced | Async validation during typing | Username availability (with 300ms delay) |
Usage Guidelines
When to use
- •For all user input forms requiring data validation
- •When checking data format (email, phone, date)
- •For required fields that must be filled
- •When validating against backend data (username, email availability)
Best practices
- •Validate on blur, not on input (avoid premature errors)
- •Provide clear, actionable error messages
- •Show success states when validation passes
- •Preserve user input - never clear fields on error
- •Debounce async validation to avoid excessive API calls
Accessibility
- •Error messages announced with aria-live="polite"
- •Invalid fields marked with aria-invalid="true"
- •Error messages linked with aria-describedby
- •Required fields indicated with aria-required
- •Focus moved to first invalid field on form submission
Do's and Don'ts
✓ Do
- ✓"Please enter a valid email address (e.g., you@example.com)"
- ✓"Password must be at least 8 characters and include one number"
- ✓"This username is already taken. Try adding numbers or underscores"
✗ Don't
- ✗"Invalid input" (too vague)
- ✗"Error: VALIDATION_FAILED_001" (technical jargon)
- ✗"Wrong!" (not helpful)