_Typesafe forms in React? Sounds like a job for React Hook Form and Zod!_ _Originally posted at [brendonovich.dev](https://www.brendonovich.dev/blog/the-ultimate-form-abstraction)_ --- I often see this question pop up online: > _"what's the best way to do forms in a react app?"_ Some people may recommended [Formik](https://formik.io), others may just use a ` ) } export default App; ``` Let's step through this code a bit: ```tsx const { register, handleSubmit } = useForm(); ``` `useForm` provides all the utilities you'll need to create a form. It keeps track of all the form elements, their validation logic, and just general housekeeping stuff for the library. `register` hooks up a form element to the data being managed in `useForm`, and is where you configure settings for each field - most notably the input's `name` prop and validation logic. `handleSubmit` takes the validation rules you provide to `register`, applies them to the form data, and provides the validated values to the callback in its first argument. ```tsx

{})}> ``` Instead of passing our `onSubmit` handler directly, we wrap it in `handleSubmit` so that validation and other logic can be performed. ```tsx ``` `register` returns props for the element it is being applied to, including `ref`, `name`, and `onChange` (the `ref` is how RHF allows components to be uncontrolled until validation!), so we spread its return value onto the `` element. `required` makes the browser enforce that the input is not empty when the form is submitted. ## Levelling Up With TypeScript Having something to handle forms is nice, but wouldn't it be great to know the shape of our form data? Well, we can! `useForm` has a generic parameter that can specify the type of our form data, allowing TypeScript to verify that the names used in `register` are vaild: ```tsx interface FormTypes { email: string; count: number; } const App = () => { const { register, handleSubmit } = useForm(); return ( {})}> ) } ``` Now we can be 100% sure about the names of our fields! Only problem is that we're not 100% sure about our fields' types. The `valueAsNumber` option on the `count` input tells RHF to convert the field's `value` - which is always a `string` - into a number. If `valueAsNumber` was `false`, TypeScript wouldn't complain but our `FormTypes` would not be accurrate. If only there was a way to validate types... ## That One Library Everyone's Using Enter [Zod](https://github.com/colinhacks/zod), a validation library with incredible TypeScript support that [T3 stack](https://create.t3.gg/) enjoyers talk about endlessly. RHF supports validating forms with Zod via [resolvers](https://github.com/react-hook-form/resolvers#zod), providing incredible typesafety in the process. Using Zod will require installing `zod` and `@hookform/resolvers`, then making a few changes to the above example: ```tsx import { zodResolver } from '@hookform/resolvers/zod' import { z } from 'zod' const schema = z.object({ email: z.string().email(), count: z.coerce.number() }); const App = () => { const { register, handleSubmit } = useForm({ resolver: zodResolver(schema) }); return ( ) } ``` Isn't it great! `z.coerce.number()` provides a typesafe alternative to `valueAsNumber`, and the keys of `z.object` define valid keys for `register()`. > _You could get rid of `required` from the inputs at this point, but it's usually better to let the browser handle as much validation as possible. Not to mention that a number input without `required` will provide a value of `'0'` instead of an empty string, so no error will be produced by the browser or Zod._ There's a problem though: **It's not actually typesafe.** I know, I was surprised too. Turns out resolvers can't set the generic parameter like we did with `FormTypes`, so the `data` argument of `handleSubmit` is not properly typed. Not to worry, we've got more work to do anyway. ## A Typesafe Coincidence If you're anything like me you'll see `resolver: zodResolver(schema)` and cringe. Apps can have many forms, meaning that line may be repeated a _lot_. Sounds like a great use for a **custom hook!** Instead of wrapping `schema` in `zodResolver`, it'd be great to pass `schema` directly to our hook. The hook will also need a generic parameter for the schema to ensure that everything is typesafe. With all that in mind, here's a hook: ```tsx import { useForm, UseFormProps } from 'react-hook-form'; import { zodResolver } from '@hookform/resolvers/zod'; import { TypeOf, ZodSchema } from 'zod'; interface UseZodFormProps extends Exclude>, 'resolver'> { schema: Z; } export const useZodForm = ({ schema, ...formProps }: UseZodFormProps) => useForm({ ...formProps, resolver: zodResolver(schema), }); ``` Don't be scared by the heap of generics on `UseZodFormProps`, they just pass the schema's type to the base `UseFormProps` type and remove the `resolver` field, and by coincidence this makes our form completely typesafe! > _Ok, it's not actually a coincidence. It's because we're passing `TypeOf` directly to `UseFormProps`, which is equivalent to doing `useForm>`._ Assuming `useZodForm` is imported, here's how things should look now: ```tsx const schema = z.object({ email: z.string(), count: z.coerce.number() }); export function App() { const { register, handleSubmit } = useZodForm({ schema }); return ( ) } ``` Here's a look at everything we've done so far: {% embed https://stackblitz.com/edit/the-ultimate-form-abstraction-p1?embed=1&file=src/App.tsx&theme=dark&view=editor&ctl=1 %} > _Sidenote: I think demos like this are a good example of what TypeScript's developer experience should be - generics behind the scenes propagating input types from inside RHF all the way out to our application code. Libraries like [tRPC](https://trpc.io) and [TanStack Query/Router](https://tanstack.com/) manage to do a similar thing._ ## When Things Go Wrong So far we've been focused on handling successful submissions, but what about when validation fails? It would be nice to display error messages below the inputs, and have those messages be sourced directly from RHF. Luckily, we can access all data about the form via `formState`: ```tsx const App = () => { const { register, handleSubmit, formState } = useZodForm(...); return ( ); } ``` It could work... but it's not pretty. Seeing as pretty much all inputs will need this functionality, maybe a component that contains both the input and error message would be nicer? Sounds like a great idea, but where would `formState` come from? Lucky for us, RHF provides utilities to make forms accessible from [context] https://beta.reactjs.org/learn/passing-data-deeply-with-context): - [`FormProvider`](https://react-hook-form.com/api/formprovider) is an easy way to make a form accessible via context - [`useFormContext`](https://react-hook-form.com/api/useformcontext) provides access to the form given to `FormProvider` With them in mind, let's take a look at our new input component: ```tsx import { ComponentProps, forwardRef } from 'react'; import { useFormContext } from 'react-hook-form'; interface Props extends ComponentProps<'input'> { name: string; } const Input = forwardRef((props, ref) => { const form = useFormContext(); const state = form.getFieldState(props.name); return (

{state.error &&

{state.error.message}

}

); }); export default Input; ``` - The component's `Props` type is almost identical to a regular `` element's props, except we make `name` required as it is needed to fetch the field's state. The value for `name` is passed through by `register()`. - [`forwardRef`](https://beta.reactjs.org/reference/react/forwardRef) is used since `register()` assigns a ref on the `` element. - All of the component's props are spread onto the ``, and the ref provided by `forwardRef` is also passed through. Great, now we have a component that can access field state via form context! We're still missing the `FormProvider` though. Seeing as all our forms will need to be wrapped in their own `FormProvider`, this seems like a great time to create another component! While we're at it, let's also wrap everything in a `

`. Not only is this good [Semantic HTML](https://developer.mozilla.org/en-US/docs/Glossary/Semantics), but `

` is unique in that it propagates its `disabled` attribute to form elements within it, making styling for loading and disabled states much simpler! ```tsx import { ComponentProps } from 'react'; import { FieldValues, FormProvider, SubmitHandler, UseFormReturn, } from 'react-hook-form'; interface Props extends Omit, 'onSubmit'> { form: UseFormReturn; onSubmit: SubmitHandler; } const Form = ({ form, onSubmit, children, ...props }: Props) => ( ); export default Form; ``` - The component takes the result of `useZodForm` in its `form` prop, which is then spread onto `FormProvider` - The type of the `onSubmit` prop is overridden to have correct types (the `Omit<..., 'onSubmit'>` is necessary to please TypeScript) - As before the `

` element's `onSubmit` is wrapped in `handleSubmit`, only now that wrapper is coming from the `form` prop instead of being defined earlier in the component - `

` has its `disabled` prop set to the form's `isSubmitting` state so that all form inputs become disabled while the `onSubmit` function is running Continuing the trend of turning everything into a custom component, why not make a `SubmitButton` component that we know will _always_ have `type="submit"`? > _This is more of a personal preference, feel free to not do this_ ```tsx import { ComponentProps } from 'react'; interface Props extends Omit, 'type'> {} const SubmitButton = (props: Props) =>

brendonovich

The Ultimate Form Abstraction

Join Our Newsletter. No Spam, Only the good stuff.