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.