`isDefaultValue` is wrong when a field-level `defaultValue` is `null`
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 76/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- typescript
- Domain
- frontend
Research direction
Read the default-value derivation in packages/form-core/src/FormApi.ts around the linked lines 1236–1241, then compare it with the field-level default handling described for FieldApi and form.reset(). Reproduce the issue with the TypeScript snippet using @tanstack/form-core. Done means isDefaultValue is true exactly for the value reset restores, including when the field default is null.
Written by the indexing model from the issue text.
Description
Describe the bug
When a field has defaultValue: null and the form-level default for that field is anything other than null (missing, undefined, or a different value), isDefaultValue does not match what form.reset() restores:
- The field holds its default (
null) butfield.state.meta.isDefaultValueandform.state.isDefaultValuearefalse, right after mount and afterform.reset(). - Setting the value to the form-level default (or to
undefinedwhen there is none) reportsisDefaultValue: true, althoughform.reset()then changes the value back tonull.
Field-level defaults of 0, false, '' or any non-null value work as expected.
Your minimal, reproducible example
The snippet under "Steps to reproduce" is self-contained and only needs @tanstack/form-core.
Steps to reproduce
import { FieldApi, FormApi } from '@tanstack/form-core'
const form = new FormApi({
defaultValues: { name: 'form' as string | null },
})
form.mount()
const field = new FieldApi({ form, name: 'name', defaultValue: null })
field.mount()
console.log(field.state.value, field.state.meta.isDefaultValue)
// null false (expected: null true)
field.setValue('form')
console.log(field.state.meta.isDefaultValue)
// true (expected: false)
form.reset()
console.log(field.state.value, field.state.meta.isDefaultValue)
// null false (expected: null true)
Without a form-level default for the field (defaultValues: {} as { name?: string | null }), the result is the same, and field.setValue(undefined) reports isDefaultValue: true.
Expected behavior
isDefaultValue should be true exactly when the current value is the one form.reset() restores, as established in #1973 and #2006. With a field-level defaultValue: null that value is null.
How often does this bug happen?
Every time
Screenshots or Videos
No response
Platform
macOS, reproduced in Node with Vitest (no browser involved)
TanStack Form adapter
vanilla
TanStack Form version
v1.33.5
TypeScript version
v5.9.3
Additional context
The derivation resolves the default with fieldDefault ?? formDefault, so a field-level null falls through to the form-level default:
https://github.com/TanStack/form/blob/2216fdedf0a5ff17e4ef8567e1321442639b96ca/packages/form-core/src/FormApi.ts#L1236-L1241
form.reset() and FieldApi treat a field-level default as set when it is !== undefined, so null is applied as a default there. This was introduced in #2006 (1.32.0) and noted in an unanswered review comment: https://github.com/TanStack/form/pull/2006#discussion_r3215386716
Related: #2425 fixes the same ?? in resetField. This issue is separate, since it also affects mount and form.reset().
Happy to open a PR if a fix is wanted on the 1.x line.
- Dominant language
- TypeScript
- Stars
- 6.7k
- Forks
- 693
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 12
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from TanStack/form
-
Async validator doesn't re-trigger `isValidating` after first failed validationPossibly taken @drewsephski claimed this 6 days ago. Open
Difficulty 2/5 1-2 days Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
[v2 alpha] devtools are always light modePossibly taken @dikshit-n claimed this 40 days ago. Openarea: runtime scope: devtools type: bug v2
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
FormGroupApi.getRelatedFields and FieldApi.validate() use unguarded startsWith for group membership, matching unrelated fields with a shared name prefixPossibly taken @HDPark95 claimed this 59 days ago. Openarea: runtime scope: core type: bug v1
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
TanStack/form#2337 · 1 comment ·
Maintainers usually reply within 1 day
-
FormApi: onSubmit/onServer error cleared on any non-matching validation cause, not just 'change'May be free again A pull request for this issue was closed without being merged. Openv1 v2: needs investigation
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
setFieldValue clears errorMap.onMount but leaves errorSourceMap.onMount stalePossibly taken @alliasgher claimed this 46 days ago. Openv1 v2: needs investigation
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
TanStack/form#2294 · 1 comment ·
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
one-zero-eight/apply-bot#39 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
bigbluebutton/bbb-ui-components-react#108 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
high priority
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
CI-CMG/deep-sea-corals-exb#84 · 1 comment ·