The most detailed free FDE + DevOps library: 140+ lessons, 70+ labs and 80 long-form articles, in English and Turkish. Start learning →

Build with AI: From Zero to Your First App · Module 5: Turn a page into an app

Validation That Says What to Fix

'Invalid input' helps nobody. This lesson writes errors that name the field, state the rule, and keep the visitor's work intact.

10 min reading

Objectives

  • Write error messages that name the field and the fix
  • Validate on submit with per-field messages, not one alert
  • Keep entered values when showing errors
  • Separate warnings (unusual but allowed) from errors (blocked)

Why this matters

A blocked submit with "Invalid input" sends the visitor hunting across the form; most give up. A message under the field saying "Pickup time is missing: choose Friday 10:00 or later" sends them to one box with the rule attached. Validation is teaching, not gatekeeping: every error is a sentence that turns a failed submit into a successful retry.

Concepts

Message shape: field plus rule plus example. "Phone number needs 10 digits: e.g. 555 010 2030." Never "error", never a code, never blame ("you failed to..."). One message per field, shown next to the field, all messages visible after one submit. The visitor fixes everything in one retry, not one field per round trip.

Keep the work. Errors must never wipe entered values. Re-rendering a cleared form punishes the visitor for your missing validation and guarantees abandonment. Validate, show messages, keep every typed character where it was.

Errors versus warnings. Errors block submit (missing name, impossible time). Warnings allow it with a note ("20 loaves is a large order; we will call to confirm"). Beginners block everything or nothing; the distinction keeps big-but-real orders flowing while catching impossible ones.

Validate the same things the brief promised. Acceptance criteria from M02L8 become validation rules: "name required", "pickup time Friday or later", "quantity 1 to 50". The brief, the criteria and the validation are one line of intent in three costumes.

Worked example

Bakery order submit with empty name and past pickup time. Bad: alert("Invalid input"), form cleared. Good: under name, "Your name is missing: write the name we should call out." Under time, "Pickup time has passed: choose Friday 10:00 or later." Values kept, two messages, one retry succeeds. Same submit, different sentences, different business afterwards.

Expected result: your form validating on submit with per-field messages that name field, rule and example, values preserved.

The common wrong move

Validating field by field with an alert per field (three submits to learn three problems). Show all messages after one submit; respect the visitor's time like you respect your own debugging time.

Lab and next step

Lab A14 adds per-field validation to the calculator with kept values. Next, lesson 19 saves data across reloads: browser storage, its limits stated honestly.

Quick check

An optional 4-question self-check. Answers never leave your device, are not stored, and never count toward any assessment.

Lesson feedback

No published feedback yet.

Log in and complete the lesson to leave feedback.

Exercise

Rewrite every validation message on your form as field plus rule plus example. Submit with three faults at once; confirm all messages show together and values are kept.

Pass criteria

Messages in field/rule/example shape next to each field; multi-fault submit shows all messages at once; entered values preserved after the failed submit.

Log in to track progressFree account: stores only your lesson progress and quiz results.