What are UI state and forms?
Forms are where users give your app data, and they are deceptively tricky: controlled inputs, validation, error display, submission states, and accessibility. Getting them right is a large part of building a usable client, and it connects directly to the server-side validation node later.
Why it matters
Almost every app collects input — signup, search, checkout, settings. Bad forms frustrate users and lose conversions. Good forms validate clearly, handle errors gracefully, and stay accessible. Full-stack developers build both the form and the endpoint it submits to, so client validation must pair with server validation.
What to learn
- Controlled versus uncontrolled inputs
- Form libraries like React Hook Form
- Client-side validation with a schema (Zod)
- Showing validation errors accessibly
- Submission, loading, and error states
- Why client validation never replaces server validation
- Accessible labels and focus management
Common pitfall
Treating client-side validation as security. It is purely UX — a fast hint to the user — and anyone can bypass it by calling the API directly. Validate on the client for experience and always re-validate on the server for safety. Skipping server validation because the form already checks is a real vulnerability.
Resources
Primary (free):
- React Hook Form — Docs · docs
- Zod — Documentation · docs
- MDN — Form validation · docs
Practice
Build a form with React Hook Form and a Zod schema: controlled inputs, accessible labels, inline validation errors, and submission/loading states. Then note where the same Zod schema will run on the server. Done when the form validates clearly on the client and is ready to validate again server-side.
Outcomes
- Build controlled, accessible forms.
- Validate on the client with a schema.
- Handle submission, loading, and error states.
- Understand client validation is UX, not security.