Why did shadcn/ui move away from <Form> to direct integration with RHF / TanStack Form?

[nmthuann]

Hello everyone,

Previously, shadcn/ui examples commonly used the <Form> component from @/components/ui/form to build forms. However, in more recent examples and documentation, the recommended approach seems to integrate fields directly with form frameworks like React Hook Form or TanStack Form.

I’d like to understand the reason behind this change. Is it to improve flexibility, reduce abstraction, or better support multiple form libraries?

I’d appreciate any insights from the community. Thank you!

[krishparmar22242]

Here is the reason why that

wrapper is being set aside in favor of direct integration.

It removes the Black Box
The original component was a thin wrapper around React Hook Form's context provider. While it made the code look shorter, it hid the underlying logic. When a form didn't submit or validation failed, developers often got frustrated because they didn't know if the bug was in their code, React Hook Form, or the shadcn wrapper. By using the libraries directly, you see exactly how the data is moving.

Freedom to choose your tools
React Hook Form is amazing, but TanStack Form has become huge lately because of its incredible type safety. If shadcn provides a rigid component, it has to decide which library to support. By moving toward direct integration, shadcn becomes form-agnostic. You can use the exact same UI components whether you are an RHF fan or a TanStack Form enthusiast.

Easier for complex forms
We’ve all been there trying to do something advanced like cross-field validation or dynamic fields, only to realize the easy wrapper makes it harder. Sticking to the standard patterns of the form library itself means you can just follow their official documentation without having to translate it into shadcn-speak.

Better for copy-pasting (Blocks)
With the new shadcn/ui Blocks, the goal is to let you copy an entire dashboard page and have it work instantly. Relying on the standard library patterns makes these blocks much more portable across different projects because they don't depend on a specific local wrapper configuration.

If this explanation of the helps you understand the new direction, please consider marking this as the accepted answer!

[sunnypatell]

@nmthuann the <Form> component wasn't removed. it's still at form.tsx as a thin wrapper around RHF's FormProvider. what changed is the recommended pattern.

in october 2025, shadcn introduced the <Field> component family (changelog). from shadcn's announcement:

"i made it work with all your form libraries: Server Actions, React Hook Form, TanStack Form, Bring Your Own Form."

<Field> is a layout primitive (labels, descriptions, errors, orientation) that's form-library-agnostic. the old <Form> was tightly coupled to RHF, which became a problem when:

• TanStack Form gained traction
• React 19's useActionState doesn't use RHF at all
• the create tool needed components that work without a specific form library

the current form docs present three paths: RHF + Field, TanStack Form + Field, and server actions. the old Form still works if you're using RHF, it's just not the recommended starting point.

the shift is: layout components (Field) are separated from form state management. you bring your own form library, shadcn provides the accessible field structure.

related: form redesign discussion #5332