Re-rendering a cell (by edit) renders the whole table

[danvln]

I am using the latest version 7.6.1, and I am hitting the issue that after I edit a single cell, I see the entire table being re-render.

This is similar with the issue called out here: #754 as far as I am reading.

Has been made any progress on the rendering performance for this table? I am planning to use it in a production system and this is a big blocker to move forward with it.

Thanks for any info.

[danvln]

I will update details. I am still investigating.

[bsubba]

I am also having the issue of re-rendering whole table. Did you find any solution for this?
#2836 (comment)

[stvhanna]

@danvln @bsubba I'm having the same issue. Any way to re-render just the impacted cell instead of the whole table?

[bsubba]

@stvhanna didn't autoResetPage: false help?

[stvhanna]

@bsubba Unfortunately it did not help. The delay on re-rendering ~2500 cells (100 rows x 25 columns) is substantial at 10s for each re-render.

[bsubba]

Is it possible to elaborate on what is it that you are trying to do and what is the problem?

[mugheerasadiq]

@danvln did you find any solution to stop the rendering of whole table ? I am facing the same issue but did not find any solution, Help needed

[codebex]

I am also still looking for a good way to handle these re-renders. The alternative so far has been using a virtualization library (react-virtuoso) so the number of rows is small and the re-render does not take so much time. Also, I am trying memoization of "Cell" components, but I am not sure yet if it helps.

[mugheerasadiq]

@alaindm how did you memoize the cell components ? can you please give me an idea.

[einarq]

The official stance on this library seems to be that re-rendering in react is fast, don't worry about it:
#1496 (comment)

This is a bit of a concern for us tbh. We are quite invested in this component by using it as the foundation for building a Table component for our design system, which is obviously used extensively across many of our applications.
I understand the sentiment that you should often start looking elsewhere to find performance bottlenecks, but in the end you might end up having to memoize components, and react-table makes that a bit difficult. Specifically memoizing the Row or Cell for instance doesn't work since the corresponding "row" and "cell" objects are seemingly always recreated whenever the table re-renders.
Adding more rows to the end, for instance, should not require re-rendering all existing rows as well. In addition to editing a single cell as described here.

A table with many rows and cells has always been a useful case for pure components, and I wish react-table made it possible in the future as well.
Even Dan mentions memo as a potential perf optimization in his latest blog post (albeit not the first), so it's still not completely out of fashion to prevent a few renders in React. It's an escape hatch which should still be supported imo.
https://overreacted.io/before-you-memo/

Hopefully this doesn't come across too much as a nagging complaint, I realize the author is in no way obligated to give us this component for free. Certainly appreciate the time spent on building this terrific library for us to enjoy.
Just wish it was possible to optimize it a bit more... :)

The article linked here, which is one of the top results when searching for how to optimize the table, gets around the issue by wrapping Row in React.memo. This would be my expected workaround as well, except it doesn't work when the Row needs to accept the "row" object.
#1496 (comment)

[tannerlinsley]

You're right that that some if not most of the methods/functions attached to rows and cells are being created on every render. I truly wish it was possible to alleviate this with the v7 architecture and this makes it almost impossible to memoize the component itself like you said without also calling all of the functions first, then memoizing on their results. This even plagues my own code in a few places :(

But there is good news! I'm currently working on v8 (a semi-private experimental stage repo on TanStack) which will not have this issue. It's taken a lot of internal refactoring and only a few breaking changes, but Row, cell and column models along with all of their methods and properties will all be stable by default. This will allow you to safely memo, useMemo and useCallback any of their properties. As of today, the rerendering story in v8 still uses a top-level rerender that propagates down the entire table tree and will, like you wish you could do today, incentivize memoization of components and computation where necessary to improve performance. It's possible that I explore more granular means of render signaling like subscription callbacks or even atom-based state like jotai, but that would significantly hinder the table's external controllability and complicate the innards quite a bit.

With the stability changes I've already made though, both the library's ability and your ability to memoize and optimize when needed is at least there now. Already in v8, I've been able to convert most of the up-front repeated instantiation of the row/cell API to be lazily-invoked memoized getters, which should drastically improve performance.

Either way, it should be really good. I hear you. Stay tuned :)

If you would like to preview the new version, give feedback, etc, it's currently open to my sponsorship tiers from Bronze up.

[einarq]

Wow, that sounds terrific! Thanks for the honest and detailed response, this certainly alleviates my concerns quite a bit when it comes to being heavily invested in this component for the foreseeable future.

I'll see if anything can be done re sponsorship, not up to me unfortunately :)

[cargilltay]

@tannerlinsley Does react-table have a roadmap or planned release date for v8 and this improvement?

[tannerlinsley]

My hope is to have v8 out by the 3rd quarter of 2021

[danvln]

On my side I used virtualization but honestly that's a lot of pain but it works well with 10k+ elements. But now this leads to another problem that I described here: #2798 because it makes the table customizations quite impossible (or at least not possible with my knowledge on react-table in a feasible way, without creating N number of react-tables...). If you have any advise please let me know and I'll be glad to join the discussion.
On another thought @tannerlinsley would you be able to share the v8 code, and if is not possible I am willing to start helping in this effort on private repo. For transparency, I am a coder looking to contribute and no other interest as already have a good job in tech, I don't need credits for anything.
Please let me know, and also maybe other folks might be interested in helping.

[mspalma]

Hi. Having the same problem here. Is there a release date for v8? You mentioned 3rd quarter of 2021, any specific date?
Thank you

[danv-msft]

@tannerlinsley - would you please let us know if there is any release date for v8 or a branch that's publicly available?

[tannerlinsley]

@***@***.*** is available. But it is very rudimentary right now. No docs, just types, and the repository is only available to supporter sponsor tier and higher. Tanner Linsley

…

On Jan 24, 2022, 2:47 PM -0700, danv-msft ***@***.***>, wrote: @tannerlinsley - would you please let us know if there is any release date for v8 or a branch that's publicly available? — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***>

[danv-msft]

Thanks for your quick reply, @tannerlinsley . Do you plan to make it available soon and will it be still under MIT? I'm looking to make a decision regarding a grid I'm using with my team and wanted to double check on this option as well.

[tannerlinsley]

Yep. Q1 is the goal. It will be MIT and fully open. The sponsorship rollout is just a sustainability experiment I’m doing this time around. Tanner Linsley

…

On Jan 24, 2022, 7:28 PM -0700, danv-msft ***@***.***>, wrote: Thanks for your quick reply, @tannerlinsley . Do you plan to make it available soon and will it be still under MIT? I'm looking to make a decision regarding a grid I'm using with my team and wanted to double check on this option as well. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: ***@***.***>

[luthv]

I've been fiddling with the new v8 alpha release, and it seems that the problem is still persists in v8 as well. I didn't do any virtualization or anything, just basic custom cell component.
Is there anything else we should do in v8 to optimize cell rendering?

[tannerlinsley]

The component where you trigger your data update will need to rerender regardless. Usually that’s your table component. Your cell components will also rerender in that case. First step is to make those cell renders fast with memoization. If that’s still not enough, you can React.memo your cell component and ensure it’s only receiving stable props that you want to trigger a rerender. Tanner Linsley

…

On Mar 31, 2022, 7:44 PM -0700, Luthfi M ***@***.***>, wrote: I've been fiddling with the new v8 alpha release, and it seems that the problem is still persists in v8 as well. I didn't do any virtualization or anything, just basic custom cell component. Is there anything else we should do in v8 to optimize cell rendering? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[luthv]

Thanks, I was able to prevent re-render using React.memo in my Row component, here is what I ended up with
https://codesandbox.io/s/react-table-v8-xqs8d9?file=/src/Row.js

Previously when you click on a cell, all the rows will re-render because of the change in activeRow state in the App component.

Is this the correct way to optimize react table in this particular case?
Now the problem is that the column no longer supports resizing because of the memoized row component

[tannerlinsley]

As of today, v8 is as optimized as possible (correct keys, internal memoization/stable-api, etc) without getting into user code land. The official solution moving forward:

• React.memo your rows/cells (and accept all of the tradeoffs with that approach)
• Render/work less. Pagination, virtualize or simplify your cell components.

[loganvolkers]

Working on a jotai integration to help with the granular subscription to changes. Should be very doable as a layer on top of table-core, similar to the jotai integrations for redux, zustand, xstate, valtio and other bespoke state stores.

[thomasmarr]

@loganvolkers did you make much progress with that?

[loganvolkers]

@loganvolkers did you make much progress with that?

Not yet!

[thomasmarr]

Ok - I have an editable grid where the out-of-the-box behaviour was causing perf issues. I have implemented a workaround using react-query to subscribe to values in individual cells. It's effective, but it does add some complexity.

Inserting new columns and/or changing column visibility also requires the whole grid to re-render so I am still finding a need to React.memo the cells, with a custom callback.

Both of the above are things I prefer to avoid if possible, so am definitely interested in alternatives.

[jremen]

@tannerlinsley
Well, we have 19. october 2023 and the issue with massive rerendering of table has still NOT BEEN RESOLVED.
Every select of the row will force all the cells in whole table to rerender. Every click on some input in cell will force all cells to rerender.
This is UNACCEPTABLE.

Heck, just try official examples on Code Sandbox, just put console.log to row selection example.
Everything we have done in our company is memoized. Still, no progress at all.