Build an accessible React Native form component with inline validation
Produces a typed, reusable React Native form with controlled inputs, inline validation, accessible error messaging, and submit/disabled states instead of wiring each field by hand.
You are a senior React Native engineer who ships forms that pass accessibility audits. I need a reusable, validated form component. Spec: [DESCRIBE THE FORM — e.g. 'a signup form with email, password, and opt-in checkbox' AND WHERE IT LIVES IN THE APP] Target stack: - Framework: [Expo / React Native CLI] - Form lib: [react-hook-form / none — hand-rolled] - Validation: [zod / yup / hand-rolled rules] - UI: [React Native Paper / plain StyleSheet] Requirements: 1. TypeScript throughout: a Field type, a FormSchema type, and props typed with generics so the same component works for many shapes. Mark each field required or optional and say why. 2. Controlled inputs only. No uncontrolled TextInput leaking state. Every field tracks value, touched, error, and dirty. 3. Inline validation on blur and on submit. Errors render as accessible text with accessibilityLiveRegion='polite' so screen readers announce them. Never just color the border red. 4. Submit button is disabled until the form is valid; show a disabled visual state and keep it focusable. 5. Accessibility: every input has a label, an accessibilityLabel, and its error described via accessibilityDescribedBy. Minimum 44x44 hit area. Set keyboardType and returnKeyType per field. 6. Pure and reusable: no global state, no navigation calls inside. On valid submit, call an onSubmit(values) prop. Expose reset() and a way to set an external error. 7. No deprecated APIs. Functional components and hooks only. Output, in this exact order: 1. A short rationale for the API and state-management choices. 2. The full <Form>.tsx file, generic and reusable. 3. A concrete usage example for the form I described, with the schema defined. 4. An edge-case checklist (async submit errors, fast-typing race, hardware back on Android, keyboard-avoiding behavior). Success signal: the output is good only if the form is fully controlled, validation errors are announced to screen readers, the submit button reflects validity, and a non-expert could wire it to a new schema from the example alone.
Use case
Use when you need a multi-field form (signup, checkout, settings) with consistent validation and accessible error handling instead of pasting uncontrolled TextInput snippets.
When to use this
Before building any screen with two or more input fields and validation rules. Not for single-field search bars or complex wizard flows with branch logic.
Follow-up prompts
- Add async field validation (e.g. username availability) with debounce and loading state.
- Extract the validation schema into a shared zod module so web and native stay in sync.
- Add a controlled checkbox and switch field type to the same form primitive.
- Source
- promptfork seed
- License
- CC-BY-4.0
- Published
- 6/22/2026