Repository navigation
Table doesn’t re-render with new React Compiler + React 19 #5567
Description
TanStack Table version
v8.17.3
Framework/Library version
React 19 + React Compiler
Describe the bug and the steps to reproduce it
In the repo provided, run bun install and then bun dev.
Then, add some text to the input and click add. Observe that the table doesn’t re-render when the data passed in has changed (table.getRowModel().rows doesn’t seem to be updated).
Your Minimal, Reproducible Example - (Sandbox Highly Recommended)
Screenshots or Videos (Optional)
No response
Do you intend to try to help solve this bug with your own PR?
None
Terms & Code of Conduct
- I agree to follow this project's Code of Conduct
- I understand that if my bug cannot be reliable reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.
Activity
jonahallibone commentedon May 19, 2024
This is unsurprising. This library (which I love) has been complicated to optimize since at least v7. They core instance returned from
useReactTabledoesn't rerender as one would expect in React, which means that the memoiziation that the compiler applies certainly breaks this library. I wouldn't expect a fix until v9.yongsk0066 commentedon May 23, 2024
I am also having difficulty applying the compiler due to the same issue. I am concerned that other libraries might have similar issues, making the application of the compiler worrisome.
SaveliiLukash commentedon May 25, 2024
Same exact issue.
We'll have to stick with
"use no memo"directive for now for our table component.KevinVandy commentedon May 25, 2024
Yep, use no memo on table components for now. A v9 alpha branch was recently created where we will focus on version bumping the peer dependencies for each framework that needs it.
izakfilmalter commentedon Jul 4, 2024
Seems like doing the following solves it for me: TanStack/virtual#743
ssynowiec commentedon Sep 1, 2024
I've the same problem with Next.js 15 & React 19 & Tanstack Table 8.20.5
use no memoin table component solves the problem.robahtou commentedon Oct 3, 2024
Same here. After hours of searching for a solution
use no memoFTWvictormanuelfrancodev commentedon Oct 29, 2024
sorry how is use no memo? how can I implement that?
kbumsik commentedon Oct 29, 2024
@victormanuelfrancodev Just add
"use no memo"on top of your filedezerb commentedon Nov 7, 2024
I have some issues event with
use no memowhile without this trick the table body remains empty, than with it it renders the first content but dosen't get rerender
robahtou commentedon Nov 13, 2024
@dezerb can you provide more details/code snippets? I've been using 'use no memo' without a hitch. Curious to what you are running into.
dereckquock commentedon Dec 18, 2024
ah i finally got it working, but i needed to add
'use no memo'to all files that import from@tanstack/react-table😅lephuochoai commentedon Feb 11, 2025
I have an issue rerender with sorting, although I've already added 'use no memo' at the top.
5 remaining items
tomasmenezes commentedon Mar 8, 2025
I've been having trouble with memoization as well, with the
tablereference not changing whenuseReactTableprops change, making memo diffs likeprev.table.options.data !== next.table.options.datauseless, sincetableis the same and it always returns false. Only workaround to keep performance so far has been to pass props around and explicitly diff each one, i.e.,prev.data !== next.data, for the prior example. Has been working great but the compiler completely breaks this approach as well.SukkaW commentedon Mar 10, 2025
TanStack Table's React Binding has an API design that doesn't allow you to follow the Rules of React (or React Inherichy), thus when used with React Compiler it breaks.
E.g. see this commonly used API:
This function
getHeaderGroupsis invoked in the render phase, thus React expects/requires this to be a pure function, i.e.getHeaderGroups's return value will only change when its parameter is changed. SincegetHeaderGroupshas 0 parameters, with the pure-function-only assumption/expectation, React Compiler memos the returned value oftable.getHeaderGroups()with 0 dependencies. However,table.getHeaderGroups()is not a pure function. Even without parameters, the return value will change during re-render, hence violating the rule of react.The same applies to
table.getRowModel().In short, If you are using TanStack Table's React Binding, TanStack Team is forcing you to violate the Rule of React by forcing you to use un-pure functions in the render phase.
See also the React Docs: https://react.dev/reference/rules/components-and-hooks-must-be-pure#return-values-and-arguments-to-hooks-are-immutable
The issue just demonstrates how much React knowledge the maintainers have.
fix: table rerender infinitely
GrahamQuan commentedon Mar 31, 2025
I am doing table resize, copy the code from example
https://tanstack.com/table/latest/docs/framework/react/examples/column-sizing, resize not working, turns out Its react-complier issue, adduse no memofor the componnet to fix it temporarily. Plz support react 19 and react-complier.derekperkins commentedon May 7, 2025
This comment just demonstrates how little respect you have for people who wrote a library you have found useful. Just because historical design choices aren't compatible with an experimental new compiler doesn't mean they don't understand. It's attitudes like this that burn out OSS maintainers. The rest of your comment provides value to understand why the issue is happening, and the snark is just uncalled for.
Dieber commentedon May 8, 2025
I agree with your other points, but when you write react, the bottom line is that all functions should be pure functions. While that comment did seem a bit disrespectful to the author, I think he was just using a stronger tone to show how mistakes shouldn't be made
derekperkins commentedon May 8, 2025
In an ideal world, yes, pure functions are great. In the real world, tradeoffs are made for performance reasons. The react compiler is trying to bring those two closer together. For a table library that can deal with huge amounts of data and has critical performance needs, it's not surprising that they made some choices to make the end user experience better. If the compiler can offload some of those choices, it's a win for maintainability and the ecosystem, but it's going to take some work to change the architecture.
The React core team is well aware of the tanstack ecosystem, and table in particular, and had this to say about the current situation.
SukkaW commentedon May 17, 2025
@derekperkins
This issue has existed for 12 months now. The TanStack Team has not fixed the issue yet, nor made a response, nor given a detailed explanation, until now.
The existing workarounds were found by the community, not provided by the TanStack Team. And the true reason behind this was only explained by me (instead of the TanStack Team) after months.
The fact that you only explain my comment after the issue has been made 12 months after the issue was created.
If the issue is indeed very hard for the TanStack Team to solve and has no ETA, the community will totally understand and respect, but only if the explanation is provided.
Yet, the TanStack Team hung the community out to dry, and the earliest explanation was made by me, and your detailed explanation for why the TanStack Team can't fix the issue was made months after I made my explanation.
No matter how many team members you ask to downvote me, I have already earned enough upvotes early on. This just shows how disappointed the community was until now.
Sparticuz commentedon May 17, 2025
I’m not a member of the team, but I downvoted your comment because it came across as rude. Criticizing the team’s intelligence isn’t constructive and only serves to be hurtful.
You're welcome to use a different React table component that better fits your needs, or even better, contribute a pull request to help address the issue.
derekperkins commentedon May 17, 2025
@SukkaW your entitled attitude is completely unnecessary. You're acting like this is a paid product not handling customer support, when instead, it is a community of volunteers. @KevinVandy responded twice on this thread, the first time within a week of the issue being opened. Just because an OSS library doesn't have enough time to do a major overhaul doesn't mean they "hung the community out to dry". You can be disappointed that it isn't supported by react compiler yet, but a very simple workaround has been available to opt out. If you want it done faster, feel free to contribute.
I'm not a TanStack maintainer, nor did I ask anyone to downvote you. The downvotes are likely people seeing this from the react compiler issue I referenced earlier, and not appreciating your tone.
KevinVandy commentedon May 17, 2025
Sorry, I haven't been following the past few threads on this discussion. We do want to eventually get TanStack Table to work with the React compiler, but as far as I can tell, it's going to require overhauling how TanStack Table handles state management. So I don't think V8 will be able to be compatible with the React Compiler.
This can easily be worked around by disabling the react compiler just for your hook or component that uses the
useReactTablehook.This is of course, not ideal, but the issues date back to decisions made before React recommended against the patterns that TanStack Table uses under the hood to force re-renders.
The React team is also aware of this particular issue and has documented some paths forward. This will be getting worked on, but it may still take some time for us to prepare and rescope the next v9 release, as we're both searching for ways to have the least amount of breaking changes without compromising on the performance ceiling.
smnbbrv commentedon May 19, 2025
@KevinVandy could this conversation be locked to the contributors only? I guess the most of subscribers are interested to hear the news when the new shiny table comes into live or at least beta; the new issue can be created to track the ongoing work. The workaround is there. Otherwise, this issue is doomed to receive negative posts only
KevinVandy commentedon Jul 27, 2026
closing this as it has been fixed in v9 for a while.