Subject Under Test
A 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 mui
's Autocomplete
in all my forms.
Behaviours
- It registers the
Autocomplete
component with RHF's form context - It inherits all the behaviours from
mui
's'Autocomplete
and accepts allAutocomplete
props. - It has three modes: edit, locked, and read-only. In edit mode, it renders a functional
Autocomplete
component. In locked mode and read-only mode, it renders aTextField
component. - It supports single and multiple selection modes
- It can limit the number of options it renders with
optionLimit
prop. - It has a build-in
required
validation rule - It accepts validation rules from
rules
prop. - It can be locked(non-editable in edit mode), and it would show a lock icon with a tooltip explaining why it is locked.
Variants - a design decision
The component has three variants:
-
EpicAutocomplete
, a regular auto-complete. It has the same API surface asmui
'sAutocomplete
component plus binding props for RHF. -
EpicAutocompleteWithManger
, an auto-complete with an additional option for managing options, extendsEpicAutocomplete
and has extra required props:manager
andmanagerLabel
. -
EpicAutocompleteWithUrl
, an auto-complete with a link icon button for users to navigate to the detail page of the selected entity. It extendsEpicAutocomplete
and has an extra prop:url
.
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 EpicAutocompleteBase
.
- 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.
Notes
- Each variant has its separate tests. Their tests are focused on their public APIs (props)
- No direct tests for
EpicAutocompleteBase
because three variants are testing it.
Top comments (0)