ReactJS

How to create reusable form components with React Hook Forms and Typescript

Dec 2, 2021

10 min read

Why Should I Create Reusable react-hook-form Input Components?

Like many in the React community, you've decided to use react-hook-form. While not every situation calls for creating wrapper components around react-hook-form, there are some situations where doing exactly that may be ideal. One such example might be creating a reusable component library for your organization. You might want to reuse the same validation logic and error styling in multiple projects. Maybe your project contains many large forms and in this case, reusable react-hook-form components can save you a lot of time. If you've decided reusable react-hook-form components are what's right for you and your team, it can be hard to understand how to make these components especially if you and/or your team have also decided to use Typescript.

Step 1: Create An Input Component

The first step is to create an input component. Creating an isolated component can be a good way to provide consumers of your component with a way to use inputs that aren't directly tied to validation or react-hook-form. It can also help consolidate styles and isolate input logic for easier unit testing. You can also use this component to enforce good accessibility practices by ensuring that inputs have a label, type, and name.

Step 2: Creating a Form

Before we move forward, we need a form. Let's imagine a registration form.

import React, { FC } from 'react';
import { Input } from '../atoms/input';

export const RegistrationForm: FC = () => {
  return (
    <form>
      <Input
        id="firstName"
        type="text"
        name="firstName"
        label="First Name"
        placeholder="First Name"
      />
    </form>
  );
};

Eventually, we'll want to make the first name field in this form a required field and display an error if that field is not provided, but before we can add any validation and see errors, we'll need to add a way to submit the form.

In our <RegistrationForm>, let's destructure the handleSubmit function off of our call to useForm, then use that to create an onSubmit function we'll call for our form submission:

import React, { FC } from 'react';
import { useForm } from 'react-hook-form';
import { Input } from '../atoms/input';

export type RegistrationFormFields = {
  firstName: string;
};

export const RegistrationForm: FC = () => {
  const {
    register,
    handleSubmit,
    formState: { errors },
  } = useForm<RegistrationFormFields>();

  const onSubmit = handleSubmit((data) => {
    console.log('submitting...');
  });

  return (
    <form onSubmit={onSubmit}>
      <Input
        id="firstName"
        type="text"
        name="firstName"
        label="First Name"
        placeholder="First Name"
      />
      <button
        className="mt-4 transform duration-200 py-2 px-4 bg-blue-500 text-white font-semibold rounded shadow-md hover:bg-blue-600 focus:outline-none disabled:opacity-50 focus:translate-y-1 hover:-translate-y-1"
        type="submit"
      >
        Submit
      </button>
    </form>
  );
};

We should have something that looks like this:

Step 3: Create a Validated Input Component

We want create a wrapper component that uses both our <Input> component and react-hook-form to create a reusable component that can be passed any validation rules and any potential errors. Let's make a new component called <FormInput>.

import React from 'react';
import { Input, InputProps } from '../atoms/input';

export type FormInputProps = InputProps;

export const FormInput = ({
  className,
  ...props
}: FormInputProps): JSX.Element => {
  return (
    <div className={className} aria-live="polite">
      <Input {...props} />
    </div>
  );
};

Registering Our Input with react-hook-form

Next, we need to register our input with react-hook-form. Errors and rules won't work until we do this. It may seem like our first step is to pass a register property given to us by react-hook-form to our generic <FormInput> component. When we attempt to do this, we'll encounter an issue. When defining our register property, what type should we assign to register?

import React from 'react';
import { InputProps } from '../atoms/input';

export type FormInputProps = {
  register: ???;
} & InputProps;

Let's take a look at what react-hook-form says is the type of register: Typescript Type for Register

We can see that the type of register is UserFormRegister<RegistrationFormFields>, but passing in a register property of type UserFormRegister<RegistrationFormFields> wouldn't help us keep our <FormInput> component generic. Not every form will have inputs that belong to our registration form. Each form will likely have different validation rules and errors. Now what?

The answer lies in generics. We need our <FormInput> to have a register property that can take in any type of form. Let's change the type for our <FormInput>'s properties.

import React from 'react';
import { InputProps } from '../atoms/input';

export type FormInputProps<TFormValues> = {
  register: ???;
} & InputProps;

<TFormValues> is a generic type that represents any potential form. In this case, our form type is RegistrationFormFields, but using <TFormValues> means that this component can be used in any form. Next, let's take a look at how we can pass the register property to our input.

import React from 'react';
import { UseFormRegister } from 'react-hook-form';
import { InputProps } from '../atoms/input';

export type FormInputProps<TFormValues> = {
  register?: UseFormRegister<TFormValues>;
};

Now, we can register an input used in a form of any type with react-hook-form. We aren't quite done with register yet, however. We still need to tell react-hook-form which input/field in the form we are trying to register. We'll need to do this with a name property that we will pass into the register function.

Defining the Name Property

It may seem like our new name property should be a string, because it represents the name of one of the fields in our form. Upon close inspection, we can see that the type of parameter register is expecting is a Path to one of the fields in our TFormValues.

The reason name is a Path is because our form type, TFormValues could potentially have nested fields, like objects, or arrays. For example, imagine that for some reason, instead of registering just one person, we had a list of people to register. Our RegistrationFormFields might look something like this instead:

export type RegistrationFormFields = {
  people: { firstName: string }[];
};

If the name property of our input field was just a string, we couldn't reference the name of the first or second person in our form. When name is of type Path, however we can access the fields of any nested object or array. For example, name could be people[0].firstName or people.[1].firstName.

The properties for our <FormInput> component should now look like:

import React from 'react';
import { UseFormRegister, Path } from 'react-hook-form';
import { InputProps } from '../atoms/input';

export type FormInputProps<TFormValues> = {
  name: Path<TFormValues>;
  register?: UseFormRegister<TFormValues>;
} & InputProps;

But wait! Now both InputProps and our FormInputProps have a name. These names are not the same thing either! The name in InputProps represents the native name on an HTML input element. The name in FormInputProps is a Path to the field in our form. We still want to be able to pass other native HTML attributes to our input. We'd just like to exclude name from InputProps because we are defining name as a Path FormInputProps`.

import React from 'react';
import { UseFormRegister, Path } from 'react-hook-form';
import { InputProps } from '../atoms/input';

export type FormInputProps<TFormValues> = {
  name: Path<TFormValues>;
  register?: UseFormRegister<TFormValues>;
} & Omit<InputProps, 'name'>;

The last thing we need to register our input with our react-hook form is validation rules. We will need to pass our validation rules to this <FormInput>, and then into the register function.

Defining the Rules Property

Remember, we want to be able to pass in any rules to our <FormInput> component, not just rules that apply to our registration form. Thankfully, this one is a bit easier.

import React from 'react';
import { UseFormRegister, Path, RegisterOptions } from 'react-hook-form';
import { InputProps } from '../atoms/input';

export type FormInputProps<TFormValues> = {
  name: Path<TFormValues>;
  rules?: RegisterOptions;
  register?: UseFormRegister<TFormValues>;
} & Omit<InputProps, 'name'>;

Let's use these properties to actually register, apply rules, and render our <FormInput> component. We also want to replace the <Input> component we were using with our new <FormInput> component in our <RegistrationForm>. We should have something that looks like this:

Sweet! We're still missing something though. No errors are actually displayed when we don't enter a first name. Let's fix that.

Defining the Errors Property

When defining our errors property, what type should we assign to errors? Let's take a look at what react-hook-form says the type of errors is. Typescript Type for Errors

We can see that the type of errors is:

{
  firstName?: FieldError;
}

Like before, passing in an errors property of type { firstName?: FieldError; } wouldn't help us keep our <FormInput> component generic. Not every form will have errors for a registration form. Each form will likely have errors. We'll have to use our <TFormValues> generic again:

import React from 'react';
import {
  RegisterOptions,
  DeepMap,
  FieldError,
  UseFormRegister,
  Path,
} from 'react-hook-form';
import { InputProps } from '../atoms/input';

export type FormInputProps<TFormValues> = {
  name: Path<TFormValues>;
  rules?: RegisterOptions;
  register?: UseFormRegister<TFormValues>;
  errors?: DeepMap<TFormValues, FieldError>;
} & Omit<InputProps, 'name'>;

You might be wondering how we could conclude that the type of errors should be DeepMap<TFormValues, FieldError>. This one was a bit tricky, but eventually we can find the type by looking for FieldErrors in the TS documentation for react-hook-form.

Let's pass the errors we're getting from react-hook-form in our <RegistrationForm> into the errors property of the <FormInput>. Errors Typescript Type Error

Looks like the errors type we are passing in from useForm does not match the errors type we are expecting in our <FormInput>.

The errors type we are passing in from useForm has a type that looks like this: UseForm Errors Type

The errors property we are expecting in our <FormInput> looks like this:

...
export type FormInputProps<TFormValues> = {
  ...
  errors?: DeepMap<TFormValues, FieldError>;
} & Omit<InputProps, 'name'>;

It looks like our errors property on our <FormInput> is of type DeepMap<TFormValues, FieldError>. It requires that either errors are completely empty, errors?, or that every property in our TFormValues exists on our errors. This isn't quite accurate.

There won't always be an error for every single field in our form. Our errors will dynamically change as the user inputs data. There might be an error for the firstName field, but if the firstName field is valid, there won't be an error for it. So although our RegistrationFormFields says that firstName is not optional, our errors must declare that any firstName errors are optional. We can achieve this by making our errors property on our <FormInput> a <Partial>.

...
export type FormInputProps<TFormValues> = {
  ...
  errors?: Partial<DeepMap<TFormValues, FieldError>>;
} & Omit<InputProps, 'name'>;

This means that the errors don't have to include all of the fields in our TFormValues, and with that our errors Typescript error is now gone!

Displaying Errors

To make sure that our error styling is consolidated, and the same across our inputs, we'll want to put the code to display these errors in our <FormInput> component.

Remember, errors contains all the errors for our form, not just the errors for one field. To render our errors, we'll want the get the errors relevant to this specific input. Your first instinct might be to get the errors by the name of our input, like so:

export const FormInput = <TFormValues extends Record<string, unknown>>({
  name,
  register,
  rules,
  errors,
  className,
  ...props
}: FormInputProps<TFormValues>): JSX.Element => {
  const errorMessages = errors[name];
  const hasError = !!(errors && errorMessages);

  return (
    <div className={className} aria-live="polite">
      <Input name={name} {...props} {...(register && register(name, rules))} />
      {hasError && <p>{errorMessages}</p>}
    </div>
  );
};

However, name is a Path. It could reference a field on a nested object or in an array. For example, we'd need to get errors.people[0].firstName and not errors['people[0].firstName'].

To do this, we can make use of lodash.get to retrieve the value of errors via a Path;

export const FormInput = <TFormValues extends Record<string, unknown>>({
  name,
  register,
  rules,
  errors,
  className,
  ...props
}: FormInputProps<TFormValues>): JSX.Element => {
  // If the name is in a FieldArray, it will be 'fields.index.fieldName' and errors[name] won't return anything, so we are using lodash get
  const errorMessages = get(errors, name);
  const hasError = !!(errors && errorMessages);

  return (
    <div className={className} aria-live="polite">
      <Input name={name} {...props} {...(register && register(name, rules))} />
      {hasError && <p>{errorMessages}</p>}
    </div>
  );
};

We're still missing something, though. Currently, errorMessages is an object representing each violated rule for our input.

For example, let's imagine that we had an email field in addition to our firstName field. This email field should not only be required, but should have a minimum of 4 chars entered, and match a valid email format.

If more than one rule was violated, like in the case that the email entered was both too short and didn't match the email format, our errorMessages would have multiple keys called pattern and minLength. Pattern would indicate that the email format was not valid. minLength would indicate that the email entered was not long enough.

However, most of the time, we only want to display only error message at a time. But how do we know which error message to display in an generic input component? Every form's type will be structured completely differently. We don't know what the shape of errors will be. How can we display specific error messages when the type could look like anything?

Fortunately, there's another package we can use that contains a component that can do this for us. That component is called ErrorMessage, and it is provided by @hookform/error-message. Using yarn or npm, install this package.

npm install @hookform/error-message or yarn add @hookform/error-message

Once that package is added, we can use it in our <FormInput>:

import React from 'react';
import classNames from 'classnames';
import get from 'lodash.get';

import {
  RegisterOptions,
  DeepMap,
  FieldError,
  UseFormRegister,
  Path,
} from 'react-hook-form';
import { ErrorMessage } from '@hookform/error-message';
import { Input, InputProps } from '../atoms/input';

export type FormInputProps<TFormValues> = {
  name: Path<TFormValues>;
  rules?: RegisterOptions;
  register?: UseFormRegister<TFormValues>;
  errors?: Partial<DeepMap<TFormValues, FieldError>>;
} & Omit<InputProps, 'name'>;

export const FormInput = <TFormValues extends Record<string, unknown>>({
  name,
  register,
  rules,
  errors,
  className,
  ...props
}: FormInputProps<TFormValues>): JSX.Element => {
  // If the name is in a FieldArray, it will be 'fields.index.fieldName' and errors[name] won't return anything, so we are using lodash get
  const errorMessages = get(errors, name);
  const hasError = !!(errors && errorMessages);

  return (
    <div className={className} aria-live="polite">
      <Input
        name={name}
        aria-invalid={hasError}
        className={classNames({
          'transition-colors focus:outline-none focus:ring-2 focus:ring-opacity-50 border-red-600 hover:border-red-600 focus:border-red-600 focus:ring-red-600':
            hasError,
        })}
        {...props}
        {...(register && register(name, rules))}
      />
      <ErrorMessage
        errors={errors}
        // eslint-disable-next-line @typescript-eslint/no-explicit-any
        name={name as any}
        render={({ message }) => (
          <p className="mt-1 font-serif text-sm text-left block text-red-600">
            {message}
          </p>
        )}
      />
    </div>
  );
};

The <ErrorMessage> component takes in an errors property. This is the same as the errors we passed into our <FormInput>, and represents all errors for all fields in the form.

The second property we are passing into <ErrorMessage> is name. The type of name on <ErrorMessage> does not match the name property we are taking into <FormInput>. For some reason, the name is of type FieldName<FieldValuesFromFieldErrors<DeepMap<TFormValues, FieldError>>> on the <ErrorMessage> component, but is of type Path<TFormValues> in the register call, even though both name properties represent are both the Path of a field in the form. Because the FieldValuesFromFieldErrors type isn't exported, I couldn't cast name to FieldName<FieldValuesFromFieldErrors<DeepMap<TFormValues, FieldError>>> and therefore had to cast it to any.

The last property we are passing into <ErrorMessage> is a render function. This render function gives you access to the single error message you'd like to display. You can use this function to display the message in any way you'd like.

Conclusion

You now know a bit more about extracting validation logic from react-hook-forms to create reusable components in Typescript. You can continue to use this pattern to create more form components like checkboxes, phone number inputs, select boxes and more. In my next blog, I'll cover how to use a different schema validation resolver, like yup, and how to display server side validation errors using the same components. Take a look at the demo below to see a closer to real life example.

Live Demo

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

Keionne Derousselle

Hi there ! My name is Keionne Derousselle. I am a hardworking full stack senior engineer, who loves technology! Delivering quality products is what drives me to create. When I'm not delving into tech, you can find me playing video games, reading fantasy books, watching anime, or finding new recipes to smoke on my Traeger!

@KeionneD @KeionneDerousselle

CSS Hooks: A new way to style your React apps

In the world of web development, the management of styles has always been a crucial aspect of building modern and responsive user interfaces. With the rise of CSS in JS libraries like Material UI and Chakra, developers have started creating dynamic and reusable styles using JavaScript; however, the performance implications of these libraries have led to the exploration of alternative solutions. One such solution is CSS Hooks, a library that offers a different approach to managing styles in web applications. The Problem with CSS in React and CSS in JS Libraries In React applications, you typically write styles directly with the style prop by applying classes with className, or if you’re using a framework like Material UI or Chakra then you may use the sx attribute, which is more powerful than the baseline attributes. There are some performance concerns in the case of the sx attribute specifically. The framework has to dynamically generate classes with your styles and apply them to the document whenever it is used. This can become an issue with large and complex applications as your styles will be regularly regenerated on the fly as the user navigates through the application. This has led developers to seek alternative solutions that offer similar flexibility but with better performance. Introduction to CSS Hooks CSS Hooks improve upon the aforementioned issues by pre-generating your CSS using configuration hooks. The styles that these hooks generate remain static during the lifetime of the application and are reused wherever possible. CSS variables are utilized under the hood whenever dynamic behavior is needed. By dynamic behavior, I’m referring to advanced CSS features such as pseudo-class selectors and media queries, which are both traditionally unavailable for use with inline styles. CSS Hooks utilize an interesting trick under the hood to accomplish this, which we will now explore. The Power of CSS Variables and the Fallback Trick As mentioned before, CSS variables are utilized in order to support using advanced dynamic behavior such as pseudo-selectors in our inline styles. CSS variables are core to something known as the “fallback trick”. The gist of how the fallback trick works is to have the pseudo-selector or media query toggle the state of a variable between initial and an empty invalid value, and then we put the value that we actually want to toggle as the “fallback” value in the reference to the CSS variable inside of the inline style itself. Changing this fallback value inside of an inline style essentially allows us to control the values used by the pseudo-selector without having to regenerate linked stylesheets as we only have to change the inline style attribute. This is best explained with an example: ` This plain HTML and CSS code effectively allows us to utilize the focus pseudo-selector on any element that we want using inline styles only. This is what CSS Hooks effectively does in the background when you use dynamic styles. No nasty re-renders and mucking with stylesheets needed! How to use CSS Hooks Now that we know how CSS Hooks fundamentally work, let’s try using them. The library itself is much easier to use than the aforementioned example. Installation and usage of CSS Hooks is easy. Firstly, we must install the @css-hooks/react package into a React project with the package manager of your choice (npm, pnpm yarn, etc). Once that’s done, all that’s left is a little bit of configuration. You have to first use a utility function called createHooks that is exported from the package we just installed. The result of that function returns a couple of variables in an array that can be deconstructed, the first being a stylesheet in the form of a string, and the second being a function. ` I recommend putting this in a separate file that can be imported from multiple other places in the project as this is where we will be configuring hooks across the project. We’re exporting both hooks and css, and both are important. We need to include hooks into the DOM as it contains the styles of the hooks that we’ll be referencing in our components. In your root component you need to add the following tag so that the generated CSS can be used. ` How this is done may vary based on the libraries that you are using. After that’s done, you can integrate CSS Hooks into your components while writing inline styles mostly just like you would do normally, with the only change being the addition of an additional call to the css function that we exported earlier: ` Now that the core boilerplate is set up, your components can now utilize CSS Hooks in theory; however we need to actually add some hooks to start with before we can use them, or else we’ll just be limited to basic styles in the same way that React inline styles are. Make your own hooks We can define our hooks inside of the css-hooks file that we created earlier, the same one that exports the css helper function that gets CSS Hooks working with our components. Hooks are defined in the options parameters that are currently empty. Defining a simple hook that allows us to define inline hover styles for a component is very easy and can be done as follows: ` Although both the key and the value in this example are the same, they both serve different purposes. The key is the name of the hook that we reference when we want to use it, while the value is the spec. The spec is the actual CSS selector that we’re writing. The name can be anything that you want it to be so long as it doesn’t clash with any existing style properties or hooks. Recommended hooks Although making your own hooks may be necessary at times, there is another repository provided by the CSS Hooks authors that adds a way to generate many useful hooks called @css-hooks/recommended. I highly recommend using this library to generate your hooks if at all possible, and the usage is pretty simple. Here’s an example showing how you can use it to generate media queries, color scheme specific styles and pseudo-selectors: ` Then with that done, these can be utilized as follows: ` We can also modify the hooks configuration to add our own hooks in addition to the recommended hooks by using the spread operator: ` Then that custom hook can be used by simply using its key name: ` Summary CSS Hooks offers a performant alternative to traditional CSS in JS libraries by leveraging CSS variables and providing a unique approach to managing styles in web applications. By pre-generating the stylesheet based on configured hooks and utilizing CSS Variables for dynamic behavior, developers can create reusable styles without the performance overhead associated with dynamic stylesheet generation. If you're interested in exploring CSS Hooks further, be sure to check out @CSSHooks for more information. You can also find some of the examples demonstrated here in a working app in our demos repository. Thank you for reading!...

Feb 28, 2024

5 mins

CSSReact

AI (Probably) Won’t Ruin Your Engineering Career with Ben Lesh, Adam Rackis, & Tracy Lee

In this episode of the Modern Web Podcast, hosts Tracy Lee, Ben Lesh, and Adam Rackis kick things off by discussing the progress of observables landing in the browser and the potential impact it could have on the use of RXJS. As developers, we're always on the lookout for new tools and technologies that can make our lives easier, and observables in the browser certainly have the potential to do just that. They talk about whether or not you should listen to your “customers” or have a strong vision that you want to push forward, like Ryan Carniato and his approach with Solid and Signals. The three also talk about AI tools, such as GPT and Co-Pilot, and how they are shaping the future of coding and ideation. Finally, Ben, Adam, and Tracy briefly touch on the potential impact of automation on job roles and the outsourcing of tech jobs. While automation can streamline certain tasks, it's important to remember that human creativity and problem-solving skills are irreplaceable. Download this episode here!...

Feb 16, 2024

1 min

ReactRxJSArtificial Intelligence

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

Shuchi Mittal, the Head of Cloud enablement at Honeywell, discusses how she as a leader in platform engineering has been able to transform internal platform engineering teams at other organizations by providing teams with value-added services, and how they effectively managed costs. She talks about how to treat these teams as customers, and delivering services that meet the customer needs, but also charging them for their usage. By providing policy-compliant infrastructure and unique services tailored to their requirements, platform engineering teams can showcase their commitment to supporting the success of other teams within an organization. This approach not only fosters trust but also positions platform engineering as a strategic partner rather than just a service provider. By going beyond the basic infrastructure provisioning, the platform engineering team can offer services that help development and product teams streamline their processes and improve efficiency. Shuchi shares her work at Fiserv where she implemented a chargeback system to track usage and costs effectively, incentivizing better development practices. This not only helped in managing costs but also encouraged teams to optimize their resource utilization, leading to improved overall efficiency and more easily scalable systems. Her platform engineering team recognized the importance of effectively managing financial aspects to secure upfront investment for product development. By implementing a billing system based on gigabyte hours, they aligned costs with usage, enabling teams to have a clear understanding of their resource consumption. This approach not only provided transparency but also incentivized teams to adopt cost-effective practices. By strategically managing financial aspects, the platform engineering team gained the trust of stakeholders and secured the necessary resources to drive innovation and deliver value to the organization. Shuchi’s journey of platform engineering serves as a valuable example of how a team can transition from being a basic service provider to becoming an innovation partner within an organization. By building trust, offering value-added services, and strategically managing financial aspects, the platform engineering team successfully elevated their role and became a strategic enabler of innovation. Download this episode here....

Apr 16, 2024

2 mins

Engineering LeadershipSoftware Engineering

How to create reusable form components with React Hook Forms and Typescript

Why Should I Create Reusable react-hook-form Input Components?

Step 1: Create An Input Component

Step 2: Creating a Form

Step 3: Create a Validated Input Component

Registering Our Input with react-hook-form

Defining the Name Property

Defining the Rules Property

Defining the Errors Property

Displaying Errors

Conclusion

Live Demo

Keionne Derousselle

You might also like

CSS Hooks: A new way to style your React apps

AI (Probably) Won’t Ruin Your Engineering Career with Ben Lesh, Adam Rackis, & Tracy Lee

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

You might also like

CSS Hooks: A new way to style your React apps

AI (Probably) Won’t Ruin Your Engineering Career with Ben Lesh, Adam Rackis, & Tracy Lee

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal