Repository navigation
[Compiler Bug]: TanStack Form incompatibility #35024
Description
What kind of issue is this?
- React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
- babel-plugin-react-compiler (build issue installing or using the Babel plugin)
- eslint-plugin-react-compiler (build issue installing or using the eslint plugin)
- react-compiler-healthcheck (build issue installing or using the healthcheck script)
Link to repro
Repro steps
When rendering something with an expression conditionally like this {!hidden && <input value={field.state.value} onChange={(e) => field.handleChange(e.target.value)}/>}, the "memo dependencies" to trigger a rerender are hidden and field.
This is different when rendering the input without a condition like this {<input value={field.state.value} onChange={(e) => field.handleChange(e.target.value)}/>}, the "memo dependencies" are "field.handleChange" and "field.state.value".
This change of behavior can cause some unexpected issues:
- in my case, using @tanstack/form, the field property isn't reactive in itself but its subproperties are. This prevents the input from updated its value when the user types inside the input
- if field was reactive, a change inside field that is neither the value or handleChange would trigger a rerender that shouldn't be needed
This can happen with a bool && <div> or with a bool ? <div> : <div> expression
Not really sure if this is expected behavior and if it is, what is the recommended fix.
I've opened an issue over at @tanstack/form
How often does this bug happen?
Every time
What version of React are you using?
19.0.0
What version of React Compiler are you using?
1.0.0
Activity
[-][Compiler Bug]: Conditionnal rendering[/-][+][Compiler Bug]: Conditionnal rendering causes unexpected change in memo dependencies[/+]josephsavona commentedon Oct 31, 2025
Thanks for posting
This breaks the rules of React, it means that a value which is supposed to be immutable is being mutated. This is likely because the design of the library predates the compiler, when immutability was strongly encouraged but not strictly enforced.
We have a system for telling the compiler about incompatible libraries, we can add
@tanstack/formto this list for now. We’ve previously checked in w TanStack folks about this.[-][Compiler Bug]: Conditionnal rendering causes unexpected change in memo dependencies[/-][+][Compiler Bug]: TanStack Form incompatibility [/+]JamesHyot commentedon Nov 5, 2025
Thank you for your response.
I do have (a lot) of workarounds available to me so I'm not that worried about this incompatibility.
However this is more concerning to me :
If I were to write a useMemo myself for this
{!hidden && <input value={field.state.value} onChange={(e) => field.handleChange(e.target.value)}/>}, I would have the dependencies over hidden, field.state.value and field.handleChange. It seems that when using an expression the Compiler takes a shortcut and has a dependency over hidden and field.crutchcorn commentedon Dec 1, 2025
Please don't.
To be explicit, TanStack Form should absolutely work with the compiler.
I'm not sure I understand what the exact problem is here.field.state.valueis mutable, but this mutation should be allowed by every rule of React that I've seen to date because we're explicitly re-rendering the field when this value changes.We've fixed this issue: TanStack/form#1893
This is not true and purely speculative. We've done extensive testing to ensure that Form is broadly fine with the rules of React and the compiler specifically.
In the same vein, "TanStack folks" is like 30+ people. I'm the lead on Form and I've never had a check-in about this problem from anyone "at" React ignoring a small aside with Dan on BlueSky publicly. I don't think it's fair to group us all together in the way you're doing here 😅
josephsavona commentedon Dec 2, 2025
I was trying to give the team the benefit of the doubt and avoid community backlash against your library. Just trying to help out fellow maintainers.
I have directly discussed the overall category of issue w Tanner and a couple other folks, so I (perhaps incorrectly) assumed that there was more information sharing across the Tanstack maintainers. Apologies if I got that wrong!