[v2] FieldWithValue<T> erases field.name to any instead of string

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#2,465 3 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@Priyeshshrivastav arbeitet bereits daran.

Seit 04.11.2026.

  • #2466 von @Priyeshshrivastav — offen

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
79/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
react, typescript
Bereich
backend-api-design

Rechercherichtung

Lies den Alias FieldWithValue in packages/form-core/src/types.public.ts und prüfe, wie sein erstes Typargument FieldApi field.name bestimmt. Verwende die eigenständige TypeScript-Reproduktion im Issue, um das aktuelle Verhalten und das mögliche Typargument string zu bestätigen. Das Ziel ist erreicht, wenn der Name Zahlenoperationen zurückweist, während die Typisierung des booleschen Werts und von Aktualisierungen weiterhin funktioniert; das Issue nennt keine Upstream-Testdatei.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Describe the bug

In 2.0.0-alpha.3, the recommended reusable-field prop type FieldWithValue<T> erases field.name to any, rather than widening the concrete field-path literal to string.

I understand that the helper intentionally erases the specific name, error, and owning form types. This report is not asking it to preserve a particular path such as "enabled"; it is about retaining the basic string guarantee while accepting any field path.

For example, a reusable checkbox/switch accepting FieldWithValue<boolean> gets correctly typed field.value and field.handleChange, but field.name.toFixed() and assigning field.name to a number are both accepted. This also exposes any to type-aware linting when forwarding the name to a native input.

Minimal reproducible example / steps

This reproduces in a standalone directory with the actual package name, without an npm alias, Next.js, a UI library, or the consuming application's configuration.

Install:

pnpm init
pnpm add @tanstack/[email protected] [email protected]
pnpm add -D [email protected] @types/[email protected]

Save as expected.ts:

import type { FieldWithValue } from '@tanstack/react-form'

declare const field: FieldWithValue<boolean>

// @ts-expect-error A field path is not a number.
const invalidNumber: number = field.name

// @ts-expect-error A field path does not have Number.prototype.toFixed.
field.name.toFixed()

// @ts-expect-error A boolean field cannot be updated to a string.
field.handleChange('not a boolean')

Run:

pnpm exec tsc --ignoreConfig --noEmit --strict --skipLibCheck --module NodeNext --target ES2022 expected.ts

Actual result:

expected.ts(5,1): error TS2578: Unused '@ts-expect-error' directive.
expected.ts(8,1): error TS2578: Unused '@ts-expect-error' directive.

The third directive is correctly consumed, confirming value typing is preserved. Removing the first two directives makes the entire file compile successfully, even though the numeric operations are invalid for a field-path string.

I also verified in a separate TSX reproduction that useForm({ defaultValues: { enabled: false } }) supplies the literal "enabled" to the <form.Field name="enabled"> render prop. Passing that field into a component accepting FieldWithValue<boolean> is where the name becomes any; wrapping the reusable component with getFormHookHelpers().fieldComponent.loose is not necessary to trigger the issue.

Expected behavior

FieldWithValue<T>['name'] should be string, while the value/update types remain T and the component can still accept fields at arbitrary paths. The first two directives above should be consumed rather than reported as unused.

Suspected cause / possible direction

The published alias is:

type FieldWithValue<TFieldValue> = FieldApi<any, TFieldValue, any, any, any>

FieldApi exposes get name(): TFieldName, so the first any directly becomes the property's type. The same definition is still present on the alpha branch at 2b4fc5c.

Could that first argument be string instead? I tested a local candidate alias FieldApi<string, TFieldValue, any, any, any> without modifying the installed library. It rejects both invalid name operations, preserves boolean update checking, accepts the concrete field from the render prop, and is accepted by both fieldComponent.strict and fieldComponent.loose in the minimal TSX reproduction. This is a candidate direction, not a claim that the full upstream suite has been checked.

Frequency

Every time.

Platform

Linux; compile-time TypeScript issue, no browser required.

TanStack Form adapter

react-form (the alias is defined in form-core).

TanStack Form version

@tanstack/react-form and its @tanstack/form-core dependency: 2.0.0-alpha.3 (current npm alpha tag when checked).

TypeScript version

7.0.2. Standalone reproduction uses React 19.3.1 and @types/react 19.3.0.

Vorherrschende Sprache
TypeScript
Sterne
6.8k
Forks
705
Ø Merge
1 T. 6 Std.
Gemergte PRs (30 T.)
12

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus TanStack/form

Alle Issues in TanStack/form

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.