Form Validation Application

A form-validation application displays field errors while preserving typed valid output. Browsers supply strings; validation must convert and check required fields. Client checks are for feedback, not for access control, so repeat validation on the backend.

The discriminated result carries either validated data or an array of error messages. A real browser form shows these messages near the corresponding inputs.

Casting form strings to typed values cannot replace parsing, and successful browser validation must not be trusted by the server.

This source was compiled using TypeScript 5.8.3 with strict checking, then executed with Node.js 22.16.0. Its stdout below is the actual captured output. The core logic is runnable without a framework or a remote API; integration-specific examples appear in a separate lab when needed.

TypeScript source

type Registration = { name: string; age: number };
type FormResult = { ok: true; data: Registration } | { ok: false; errors: string[] };
function submit(nameText: string, ageText: string): FormResult {
  const errors: string[] = [];
  const name = nameText.trim();
  const age = Number(ageText);
  if (name.length < 2) errors.push("Name too short");
  if (!Number.isInteger(age) || age < 13) errors.push("Age must be 13+");
  return errors.length ? { ok: false, errors } : { ok: true, data: { name, age } };
}
console.log(submit("Maya", "16"));
console.log(submit("A", "bad"));

Verified output

{ ok: true, data: { name: 'Maya', age: 16 } }
{ ok: false, errors: [ 'Name too short', 'Age must be 13+' ] }

Compile: npx tsc --strict --target es2022 --module commonjs form-validation-application.ts; run: node form-validation-application.js. For examples importing node: modules, install @types/node as a development dependency; for browser or React projects use the separate lab setup.

The discriminated result carries either validated data or an array of error messages. A real browser form shows these messages near the corresponding inputs.

Before editing the code, predict what the output will be for one changed input. Run it and compare your prediction with the actual result.

Casting form strings to typed values cannot replace parsing, and successful browser validation must not be trusted by the server.

Determine whether the issue belongs to the type system, a trust boundary, or actual runtime behavior before choosing a correction.

Build a two-field HTML form and connect it to this submit function. Disable submission only after displaying all errors.

Record expected success and failure outcomes, run the code, and compare the observed behavior. Keep the exercise compatible with strict type checking.

The discriminated result carries either validated data or an array of error messages. A real browser form shows these messages near the corresponding inputs.

Apply the same reasoning to the practice task, then integrate it into a real app only when the runtime and dependency setup are ready.