React Forms: Is Formik still worth it?

Forms are one of those things that seem simple on the surface and turn into a rabbit hole the moment you need real-world requirements: validation, async submission, error messages per field, touched state, conditional fields, and unit tests that don’t make you want to quit.

In the React ecosystem, Formik dominated that problem space for years. Written by Jared Palmer in 2017 out of frustration with Redux Form, it became the de facto answer to “how do we manage forms in React?” But five years is a long time in JavaScript, and the landscape has shifted. This article is an honest look at where Formik stands today, what Yup brings to the table, and whether you should reach for something else.

What Formik Gets Right

Formik’s core philosophy is that the three painful parts of form handling are: keeping track of values, orchestrating validation, and managing submission state. It handles all three and stays out of the way for everything else.

Its API is explicit and readable. State lives in one place — the <Formik> component or the useFormik hook — and it exposes helpers like handleChange, handleBlur, handleSubmit, along with the values, errors, and touched objects. A team member who has never seen Formik before can read a form component and understand what’s happening without having to look up documentation.

The component-based API (<Formik>, <Form>, <Field>, <ErrorMessage>) means you can build declarative forms with very little boilerplate. <Field> automatically wires up onChange, onBlur, and value from the parent Formik context, and <ErrorMessage> renders the validation message for a named field only when it has been touched. For the majority of forms — login, registration, settings, checkout — this covers everything.

Since v2, Formik also exposes a useFormikContext hook that lets nested components access form state without prop-drilling. This is particularly useful when building reusable field components in a design system:

import { useFormikContext } from 'formik';

function SubmitButton() {
  const { isSubmitting, isValid } = useFormikContext();
  return (
    <button type="submit" disabled={isSubmitting || !isValid}>
      {isSubmitting ? 'Saving…' : 'Submit'}
    </button>
  );
}

This pattern makes complex form layouts clean and avoids passing form state through layers of components.

Yup: Validation as a First-Class Concern

One of Formik’s most important decisions was not building a validation library. Instead, it integrates natively with Yup, a schema-based validator for JavaScript objects.

Yup schemas describe the shape and constraints of your data in a chainable, declarative syntax:

import * as Yup from 'yup';

const schema = Yup.object({
  name: Yup.string().required('Name is required'),
  email: Yup.string().email('Must be a valid email').required('Required'),
  age: Yup.number().min(18, 'Must be at least 18').nullable(),
  website: Yup.string().url('Enter a valid URL').optional(),
});

You pass this schema to Formik’s validationSchema prop, and it automatically transforms Yup’s validation errors into the errors object that matches your initialValues. There’s no glue code.

Beyond simple string and email validation, Yup handles nested objects, arrays, conditional rules (when), async validators (e.g. checking username availability against an API), and cross-field dependencies. For teams working on complex enterprise forms — particularly in healthcare, finance, or SaaS — Yup’s expressiveness is a genuine advantage over writing custom validation functions.

Yup also pairs well with TypeScript. Using yup.InferType<typeof schema> gives you a type inferred from your schema, which you can use as the generic type for useFormik<FormValues>() to keep everything in sync without maintaining a separate interface.

Testing Forms: React Testing Library

The original version of this article recommended wrapping fireEvent calls in the deprecated wait() utility. Testing Library has since moved to waitFor, which is both more accurate and better aligned with how React’s event loop processes async state updates.

The bigger principle here is still valid and worth emphasizing: test your forms the way users use them. That means querying by label text, role, or placeholder rather than CSS selectors, and firing events that reflect real user behavior.

import { render, screen, fireEvent, waitFor } from '@testing-library/react';
import userEvent from '@testing-library/user-event';

it('shows a validation error when email is empty', async () => {
  render(<SignupForm />);
  await userEvent.click(screen.getByRole('button', { name: /submit/i }));
  expect(await screen.findByText(/email is required/i)).toBeInTheDocument();
});

Note the use of userEvent (from @testing-library/user-event) rather than fireEvent for typing and clicking. userEvent simulates full browser-level event sequences — focus, keydown, keyup, input, change, blur — and catches issues that fireEvent misses. It’s now the recommended approach.

Because Formik triggers async state updates internally, you will almost always need await and either waitFor or findBy queries (which wait for the DOM to update). This is not a quirk to work around — it accurately reflects that validation and submission are asynchronous operations, even when they feel instant.

The Elephant in the Room: Is Formik Still Maintained?

This is where the honest answer matters. As of early 2025, Formik is in maintenance mode. The last meaningful release was v2.4.x, and its creator, Jared Palmer, has moved on to other projects. The GitHub repository still accepts bug fixes from community contributors, but there is no active roadmap, no React 19 adaptation story, and the library carries around 44KB gzipped — more than three times the size of its main competitor.

The npm download numbers tell the same story: React Hook Form has more than doubled Formik’s weekly downloads. In 2020, recommending Formik was a safe default. In 2025, it requires justification.

React Hook Form: The Current Consensus

React Hook Form (RHF) was built specifically to address Formik’s architectural limitations. Its key design decision is using uncontrolled inputs under the hood — it registers inputs via a ref rather than managing their value through React state. This means typing in a field does not trigger a re-render of the entire form, which is a significant performance difference in forms with many fields.

The surface API is minimal: useForm() returns register, handleSubmit, formState, and a few other helpers. A basic field looks like:

const { register, handleSubmit, formState: { errors } } = useForm();

<input {...register('email', { required: 'Email is required' })} />
{errors.email && <p>{errors.email.message}</p>}

RHF also supports Yup for schema validation via @hookform/resolvers/yup, so your existing Yup schemas are fully portable. It additionally supports Zod — which has grown rapidly as the TypeScript-first validation library — making it a better fit for teams that have moved in that direction.

The tradeoffs are real though. Uncontrolled inputs mean the form state is less visible — you can’t easily inspect values at any moment the way you can with Formik. Debugging is harder. Integrating with controlled third-party components (rich text editors, custom date pickers, design system components) requires using RHF’s Controller wrapper rather than just spreading props. Teams that value explicit, traceable state will find Formik more comfortable to reason about.

RHF’s TypeScript integration is tighter — generics work naturally from day one, making it the better choice for large TypeScript codebases. Its bundle size (approximately 12KB gzipped, zero dependencies) is also meaningfully better for performance-sensitive applications.

Which Should Your Team Choose?

The right answer depends on your context more than it depends on benchmarks.

Reach for Formik if:

• You are maintaining an existing Formik codebase. There is no compelling reason to rewrite working forms.
• Your team values readability and explicit state over performance.
• Your forms are moderately complex — registration flows, settings pages, multi-field forms — where re-render overhead is negligible.
• You are onboarding junior developers who benefit from Formik’s more self-documenting API.

Reach for React Hook Form if:

• You are starting a new project or greenfielding a form layer.
• Performance is a concern — particularly large forms with many fields, or forms that are rendered frequently (e.g. inside a data grid).
• You are working in TypeScript and want the cleanest generics experience.
• You want a smaller bundle and zero dependencies.

Consider neither if:

• You are building simple, one-off forms with minimal validation. Native HTML validation (required, type=”email”, pattern) combined with FormData is often sufficient and ships zero JavaScript.
• You are on React 19, which introduces useActionState and form actions that handle pending state and server-side mutations natively. For server-centric applications using React Server Components, the built-in primitives cover a surprising amount of ground without any library at all.

Bottom Line

Formik’s contribution to the React ecosystem was real — it standardized form handling at a time when the alternatives were Redux Form or rolling everything by hand. The patterns it established (a single source of truth for form state, integration with Yup for schema validation, explicit touched and error objects) are still sound.

But libraries age, and Formik has aged. React Hook Form is the current community consensus for new projects, with better performance, a smaller footprint, and active development. If your team is starting fresh, that is the safer long-term bet.

What hasn’t changed: Yup remains an excellent choice for validation regardless of which library you pair it with, and React Testing Library remains the right tool for testing forms — not because it makes tests easier to write, but because it makes them test the right things.