mui auto-complete adaptor component integrated with React Hook Form's form context. It uses the
Controller component from React Hook Form(RHF) and configures mui's
Autocomplete to handle validations and more. I use this component instead of
Autocomplete in all my forms.
- It registers the
Autocompletecomponent with RHF's form context
- It inherits all the behaviours from
Autocompleteand accepts all
- It has three modes: edit, locked, and read-only. In edit mode, it renders a functional
Autocompletecomponent. In locked mode and read-only mode, it renders a
- It supports single and multiple selection modes
- It can limit the number of options it renders with
- It has a build-in
- It accepts validation rules from
- It can be locked(non-editable in edit mode), and it would show a lock icon with a tooltip explaining why it is locked.
The component has three variants:
EpicAutocomplete, a regular auto-complete. It has the same API surface as
Autocompletecomponent plus binding props for RHF.
EpicAutocompleteWithManger, an auto-complete with an additional option for managing options, extends
EpicAutocompleteand has extra required props:
EpicAutocompleteWithUrl, an auto-complete with a link icon button for users to navigate to the detail page of the selected entity. It extends
EpicAutocompleteand has an extra prop:
Before writing the tests for this component, I did not have the above variants, and all the functions were crammed into a single component, which was a leaky implementation.
- Many instances don't need the manager or URL but carry the baggage with them.
- URL require
react-router, and it adds unnecessary dependencies to users that don't use it
- The component internals are too complicated.
For the new structure, I moved the implementations into a base component called
- It is private and not exposed to external libraries. It cannot be used in forms directly.
- All three variants are composed of it.
With the above design, the API for the variants are more precise and lean, and they don't carry unnecessary dependencies with them.
I sincerely invite suggestions from my dear readers for a better approach.
- Each variant has its separate tests. Their tests are focused on their public APIs (props)
- No direct tests for
EpicAutocompleteBasebecause three variants are testing it.