How to cleanly type FieldApi props for reusable sub-components without providing 23 generic arguments?

[hadikman]

Hi everyone!I am building a reusable component that needs to accept a form field instance as a prop. My field value is strictly typed using a Zod schema (MultiPriceItem[]), but when I try to pass it to FieldApi, TypeScript throws an error because the class requires 23 explicit generic type arguments.Here is a simplified look at my Zod schema and my component's props interface:

import { FieldApi } from '@tanstack/react-form'
import { z } from 'zod'

export const MultiPriceItemSchema = z.object({
  id: z.string().min(1),
  name: z.string().min(1),
  price: z.number(),
  // ... other properties
})

export type MultiPriceItem = z.infer<typeof MultiPriceItemSchema>

interface TreeNodeRowsProps {
  node: MultiPriceTreeNode
  // ❌ Error: Generic type 'FieldApi<...>' requires 23 type argument(s).
  field: FieldApi<any, any, MultiPriceItem[]> 
  items: MultiPriceItem[]
  onAddChild: (parentId: string, parentDeep: number) => void
  onRemove: (itemId: string) => void
}

What I've tried:

1. Using AnyFieldApi: This works to bypass the error, but I lose internal type safety because field.state.value becomes any. I want my component to strictly know that the field value is MultiPriceItem[].
2. Padding with any: Writing FieldApi<any, any, MultiPriceItem[], any, any, ...> twenty-three times feels like an anti-pattern and is highly unmaintainable if the library updates its internal architecture.

My Question:
What is the recommended, idiomatic way in TanStack Form to strongly type the TData (value) of a FieldApi instance inside reusable sub-components without manually providing all 23 generic parameters? Is there a built-in utility type (like an InferFieldApi or similar) that I missed in the docs?

Thank you in advance! 🙌

[aymenhmaidiwastaken]

There's no InferFieldApi, and I don't think one is coming — the answer is to stop passing FieldApi as a prop at all.

Both things you noticed are real. On 1.33.2:

• FieldApi<any, any, MultiPriceItem[]> fails, because the type takes 23 arguments with no defaults.
• AnyFieldApi is literally FieldApi<any, any, any, ...> × 23, so field.state.value really is any. I checked with a compile-time probe rather than eyeballing it:

type IsAny<T> = 0 extends 1 & T ? true : false

function useB(field: AnyFieldApi) {
  const v = field.state.value
  const anyCheck: true = null as unknown as IsAny<typeof v>  // compiles -> v is any
}

So it's not that you're missing a utility type; the escape hatch really does cost you what you think it costs.

The supported route for a reusable sub-component is withFieldGroup, which binds the component to a shape instead of to a field instance:

import { createFormHook, createFormHookContexts } from '@tanstack/react-form'

const { fieldContext, formContext } = createFormHookContexts()
const { withFieldGroup } = createFormHook({
  fieldContext,
  formContext,
  fieldComponents: {},
  formComponents: {},
})

export const TreeNodeRows = withFieldGroup({
  defaultValues: [] as MultiPriceItem[],
  props: { deep: 0 },
  render: function Render({ group, deep }) {
    const value = group.state.values     // MultiPriceItem[]
    const name = value[0]?.name          // string | undefined
    // ...
  },
})

defaultValues is what carries the type — you're declaring "this component operates on a MultiPriceItem[]", and the group API is typed from that. No generic arguments anywhere.

I put the same probe through tsc --strict to confirm it isn't just inferring any again:

const typedCheck: MultiPriceItem[] = value          // assignable
const notAny: false = null as unknown as IsAny<typeof value>   // holds -> not any
const firstName: string | undefined = value[0]?.name

// @ts-expect-error  -- and typos are still caught
const bad = value[0]?.nope

All of it type-checks clean, including the @ts-expect-error firing on the bad property — which is the part that matters, since a silent any would have swallowed it.

The parent then mounts it against the matching part of the form rather than handing over a field:

<TreeNodeRows form={form} fields="items" deep={0} />

Which is the reason there's no InferFieldApi: the 23-parameter list is internal bookkeeping the library doesn't intend you to spell, so instead of a way to write it, you get withFieldGroup and withForm to avoid needing to. Your instinct that padding it with any is an anti-pattern was right — it isn't just ugly, it silently turns off the checking you set the Zod schema up for.

One caveat: if MultiPriceTreeNode is recursive and you need the group to nest into itself, withFieldGroup binds to one shape at a time, so you'd compose per level rather than recursing on a single group. Worth checking against your tree shape before committing to the refactor.

[TheSeydiCharyyev]

FieldApi isn't meant to be written by hand as a prop type — those 23 generics are internal plumbing, and there's no InferFieldApi helper (as @aymenhmaidiwastaken noted). The idiomatic way to get a reusable component with a typed field is the form composition API, where the field type comes from context instead of props.

Set up the contexts once:

// form-context.ts
import { createFormHookContexts } from '@tanstack/react-form'

export const { fieldContext, formContext, useFieldContext } =
  createFormHookContexts()

Register your reusable component as a field component:

// app-form.ts
import { createFormHook } from '@tanstack/react-form'
import { fieldContext, formContext } from './form-context'
import { TreeNodeRows } from './TreeNodeRows'

export const { useAppForm } = createFormHook({
  fieldContext,
  formContext,
  fieldComponents: { TreeNodeRows },
  formComponents: {},
})

Inside the component, pull the field from context and type it right there — no generics, and state.value is fully typed:

import { useFieldContext } from './form-context'
import type { MultiPriceItem } from './schema'

export function TreeNodeRows(props: {
  node: MultiPriceTreeNode
  items: MultiPriceItem[]
  onAddChild: (parentId: string, parentDeep: number) => void
  onRemove: (itemId: string) => void
}) {
  const field = useFieldContext<MultiPriceItem[]>()
  // field.state.value is MultiPriceItem[] — fully typed
  // ...
}

You render it through AppField's render prop, so the field instance is provided via context rather than passed as a prop:

const form = useAppForm({ /* ... */ })

<form.AppField name="prices">
  {(field) => <field.TreeNodeRows node={node} items={items} onAddChild={...} onRemove={...} />}
</form.AppField>

If you truly can't adopt the composition API and must keep a field prop, the only maintainable options are:

• type the prop as AnyFieldApi and assert at the read site: const value = field.state.value as MultiPriceItem[], or
• pass just what the child needs instead of the whole field — e.g. value: MultiPriceItem[] and onChange: (v: MultiPriceItem[]) => void — which keeps the child fully typed and decoupled from FieldApi's internals.

But useFieldContext<MultiPriceItem[]>() via createFormHook is the intended answer and the only one that stays type-safe without the FieldApi<...> generic soup.

Refs: https://tanstack.com/form/latest/docs/framework/react/guides/form-composition

[hadikman]

I used your solution, it fixed the issue
Thank you @TheSeydiCharyyev 🤜🏼🤛🏼