# react-hook-form-mui wraps Material-UI inputs so they speak react-hook-form

> react-hook-form-mui is a small adapter library that gives Material-UI form controls a react-hook-form compatible API, so text fields, selects, pickers and sliders register themselves without Controller boilerplate. It suits teams already on react-hook-form and MUI, and its sharp edge is that the wrapper decides how each control binds, which leaves some MUI props outside your reach.

**dohomi/react-hook-form-mui** — Material-UI form components ready to use with react-hook-form

- Repository: https://github.com/dohomi/react-hook-form-mui
- Website: https://react-hook-form-material-ui.vercel.app
- Stars: 643 · Forks: 124
- Language: JavaScript
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/dohomi-react-hook-form-mui

## The library is a list of named elements, not a form system

The scope is easy to read off the component list. react-hook-form-mui provides FormContainer, AutocompleteElement, TextFieldElement, SelectElement, MultiSelectElement, RadioButtonGroup, CheckboxButtonGroup, CheckboxElement, SwitchElement, PasswordElement, DatePickerElement, DateTimePickerElement, SliderElement and ToggleButtonGroupElement. Each one is a react-hook-form aware version of a Material-UI control, and each takes a name prop that becomes the field path. The description calls them opinionated use cases, and that word does the work: the library has decided which MUI props to forward and which to swallow, and it has decided the shape of the register call behind each control. The result is that a form is written as a list of elements with names, and the plumbing that usually dominates a react-hook-form codebase, the Controller wrapper with its render prop, is simply absent. That is the entire value proposition, and it is a real one for forms with a dozen or more fields.

## Two setup styles, one of which gives up the wrapper entirely

The documentation shows two ways to build a form, and the difference between them is more than stylistic. The simple setup uses FormContainer, which takes defaultValues and an onSuccess callback, and the elements inside need no control prop at all. The typesafe setup goes the other way: you call useForm yourself, keep the control it returns, and pass that control to each element, then wrap the elements in your own form element and handle submission with handleSubmit. In that second arrangement FormContainer is not involved, and the elements are just controlled inputs bound to react-hook-form. The elements are the same either way, which means a team can start with the quick form and move to the explicit style field by field as the form grows. The cost of the explicit style is that you own the form element and its submit wiring, and the benefit is that you keep access to the full react-hook-form API instead of a container that decides when submission happens.

## Installing means two packages plus the MUI date and icon packages

The install is short, and the second command is the one people miss. The library itself and react-hook-form are added together, and then the documentation says the package uses pickers and icons from the MUI ecosystem, so if you make use of it you add those to your app as well.

```bash
# npm install react-hook-form react-hook-form-mui
# yarn add react-hook-form react-hook-form-mui
```

```bash
#  npm install @mui/x-date-pickers @mui/icons-material
#  yarn add @mui/x-date-pickers @mui/icons-material
```

The peer dependency on the pickers and icons packages is a deliberate choice rather than an oversight. Bundling a copy of the date pickers inside the adapter would freeze the version a user cannot upgrade, and it would double the bundle when the app already uses MUI. Leaving them as peer dependencies means the app chooses the version and the adapter uses whatever is there. The compatibility notes that follow the install are worth reading, because the version history is not linear. From version 3 and above the package uses MUI v5, while versions 1 and 2 used Material-UI v4, and from version 6 the x-date-pickers version 6 is in use, with a note to upgrade dependencies accordingly.

## FormContainer wires a form context for sub-components

The mechanism behind FormContainer is context propagation. The documentation describes it as wiring up a form so that you can create sub-components which use useFormContext or useWatch to react to form values. This is the feature that decides whether a form lives in one file or can be split across components, which matters as soon as a form has conditional sections or reusable field groups. Because the elements read the context, a deeply nested component can watch a field and disable a button or show a summary without the parent threading props down every level. The subtle part is that this is exactly where a wrong import produces a confusing failure, and the troubleshooting section addresses it head on. The package re-exports react-hook-form, and the recommendation is to import useWatch from react-hook-form-mui rather than from react-hook-form, because a second copy of the library in the dependency tree means two separate contexts, and the context your element reads is not the one your hook reads.

## Date pickers need a provider wrapped around the form

If you use DatePickerElement, the form has to be wrapped in a provider, and the documentation points to the DateFnsProvider component in the package source for both Dayjs and DateFns examples, and the demo uses one of them. The reason is that the MUI date pickers need a date library context to work at all, and the adapter does not assume which one you use. This is a small piece of setup, and it is the kind of thing that costs an afternoon if it is missing, since a date field inside a form with no provider will fail in ways that point at the adapter rather than at the missing context. The troubleshooting guidance is worth a note on its own, because it names the same class of problem in a different form. The library re-exports react-hook-form, and the documentation says this is especially required if you have context issues of React, with the example importing useWatch from the adapter package instead of from react-hook-form itself.

## The re-export is a convenience that can cost you a second context

The troubleshooting advice deserves its own reading because it reveals a design decision with consequences. The package re-exports react-hook-form, and the stated reason is for convenient reasons this package is re-exporting react-hook-form which is especially required if you have context issues of React. The problem is that a re-export is only safe when there is exactly one copy of the underlying library in the tree. If your application depends on react-hook-form directly, and the adapter brings its own, then a component that calls useWatch from your copy reads a different context from the one the elements registered into, and the symptom is a field that never updates or an undefined context error. The example in the documentation shows the fix, importing useWatch from react-hook-form-mui. A sturdier fix is a dependency management rule in your project that prevents duplicate copies, but the documentation does not say so, and a team that hits this will spend time on the wrong layer.

## Where this adapter is the wrong choice

The first limit is the opacity of the wrapper. Each element decides how it binds to react-hook-form, and the documentation does not enumerate which MUI props are forwarded, which are consumed for the binding, and which are unreachable. If you need to set a prop that the element does not expose, you are back to writing a Controller by hand for that field, which means two ways of doing the same thing in one form. The second limit is the ecosystem fit. This library assumes react-hook-form is already the answer, and a team that has not yet compared react-hook-form with Formik or with a server-action based approach should decide that first, because the adapter adds a layer of opinion on top of a decision it does not make for you. The third is the peer dependency on the pickers and icons packages, which is right for a production app and wrong for a quick prototype, since a two-field form in a demo now pulls in the x-date-pickers and icons packages for nothing. The fourth is version churn, because the MUI generation and the pickers major version both shifted under the package's own version numbers.

## How it differs from writing the Controller yourself

The alternative for a team that already knows react-hook-form is to write the controllers directly, and the difference in approach is worth stating precisely. A hand-written Controller gives you the underlying MUI component, so every prop is available, and the binding code is visible in your repository rather than in a dependency. The adapter gives you a named element and a name prop, which removes the render prop entirely and makes a large form readable, at the cost of a layer whose internals you did not write and whose upgrade path you do not control. The middle position is usually the pragmatic one, since many forms are mostly text fields and selects with a couple of awkward fields, and the adapter is a good fit for the first kind and the hand-written controller is the right answer for the second. What the adapter does not do is replace the choice of form library, and the version history of the package, with its moves from Material-UI v4 to MUI v5 and from one major version of the date pickers to another, is a reminder that any layer between you and MUI will carry that kind of cost.

## Conclusion

Teams that have already chosen react-hook-form for form state and Material-UI for the component library are the people this adapter is for, and the win is that the common controls register themselves rather than needing a Controller wrapper each. It is the wrong choice for a team that wants direct access to the underlying MUI props on every control, because the wrapper exposes an opinionated subset, and it is the wrong choice for a project that has not settled on react-hook-form yet, since the package re-exports react-hook-form itself and quietly pulls it into your dependency graph. Check three things before you adopt it: that your MUI generation matches what the installed version expects, since versions 3 and above use MUI v5 while versions 1 and 2 used Material-UI v4, that you have added the x-date-pickers and icons-material packages if you use the picker or icon elements, and that your date fields are wrapped in the Dayjs or DateFns provider the library requires. The licence is MIT, the newest release is 9.0.0 from 2026-04-20, and the last push was on 2026-08-09.

## FAQ

### Which MUI version does react-hook-form-mui need?

From version 3 and above the package uses MUI v5, while versions 1 and 2 used Material-UI v4. From version 6 the x-date-pickers version 6 is in use, and the documentation asks you to upgrade your dependencies to match.

### Do I need to install @mui/x-date-pickers separately?

Yes, if you use the library. The README says the package utilizes pickers and icons of the MUI ecosystem, so you add @mui/x-date-pickers and @mui/icons-material to your app as well.

### How do I use a date picker with react-hook-form-mui?

If you use the DatePickerElement you have to wrap your form with a provider. The README points to the DateFnsProvider component in the package source, with examples for both Dayjs and DateFns.

### Why should I import useWatch from react-hook-form-mui?

The package re-exports react-hook-form, and the troubleshooting section recommends importing useWatch from react-hook-form-mui rather than from react-hook-form, because having two copies of the library means two different contexts and a watch that does not see the registered value.

### Which components does react-hook-form-mui provide?

FormContainer, AutocompleteElement, TextFieldElement, SelectElement, MultiSelectElement, RadioButtonGroup, CheckboxButtonGroup, CheckboxElement, SwitchElement, PasswordElement, DatePickerElement, DateTimePickerElement, SliderElement and ToggleButtonGroupElement, and a Storybook demo shows the overview.

## Sources

- [dohomi/react-hook-form-mui on GitHub](https://github.com/dohomi/react-hook-form-mui)
- [License: MIT](https://github.com/dohomi/react-hook-form-mui/blob/master/LICENSE)
- [Project website](https://react-hook-form-material-ui.vercel.app)
- [README](https://github.com/dohomi/react-hook-form-mui/blob/master/README.md)
- [Releases](https://github.com/dohomi/react-hook-form-mui/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dohomi-react-hook-form-mui