React Table v7 : Slow when updating/creating new data frequently.

[ifen]

Using react table to display a large set of data (approx 20k rows) this data is updated via web-socket periodically throughout the day (can be to create, update or delete entries) the data passed into the table is generated using a computed value linking to an array of all items. The problem is that its causing full render of the entire table every-time just a single row is added or deleted and thus makes freezes the UI for us. Are there any recommendations on how to handle this better?

[ifen]

@tannerlinsley - Was wondering if you could give me your guru insights into this query :) thank you so much for tool.

[XanMK3]

Use the virtualization Ifen!
https://react-table.js.org/examples/ui#virtualized-rows-react-window

[ifen]

@XanMK3 - we are of course that really helps, but still causing a full re-render of the entire table everytime we add a new row to the array :(

[ifen]

Use the virtualization Ifen!
https://react-table.js.org/examples/ui#virtualized-rows-react-window

The table is wrapped in an "Observed" class, so changes to the computed data are causing a total re-render of everything. If I removed the observed prop, it doesn't re render every-time but as a side effect I have stale data. So I'm a bit stuck.

[jelizarovas]

@ifen did you ever solve this issue?

[ifen]

@jelizarovas - unfortunately not, I'm still waiting for some help. As amazing as this package is, and it really is, I think react table was just not designed to have a lot of dynamic data constantly being updated and inserted (via sockets for example). Each time the table is rerendered (due to new data coming in on the socket for example) the initialisation time of react table, when I already have 50k rows, freezes the UI for a second or two till it recomputes it's internal structure. As a consequence of this, if I get even 1 update a second with new data, the table/page are totally unusable as it's constantly initializing.

[etodanik]

I'm seeing a similar story. On every single CRUD operation, as well as sort / group / filter.

The result is that the library is functioning very very slowly on any user interaction.

I'm gonna try to come up with something to speed it up...

[ifen]

please let me know if you find anything @israelidanny

[AMRUT17]

I have query regarded React-Table development.I'm new to react.js please help me.

[bentleyvk]

React.memo could help as it only renders only the new rows and old ones remain untouched. We are using it but the biggest con is that you need to check props manually. Here is a link to our implementation: https://github.com/iTwin/iTwinUI-react/blob/main/src/core/Table/TableRowMemoized.tsx

[retnag]

This still seems to be an issue with @tanstack/table-core@v8.5.5. I have a table with 10K rows, and every time I set a new data array, the ENTIRE rowModel gets recreated. This takes 2–3 seconds, and the UI is unresponsive in the meantime. I am surprised that the rows aren't cached, as most things are cached by the library. Almost all entries in my data array have the same index and are referentially equal to the data array before. It would be possible to identify which rows changed by index and reference, and skip accessing (and recreating) unmodified rows. I think that would be a general optimization, and also empower users, if they cared about this, to optimize the performance, by using immutable changes only to their data array objects. (mutable changes don't get detected by react anyway, so nothing should break because of this).

What I don't know is if it can be implemented, without breaking something inside the library? I don't know my way around the code...

[tannerlinsley]

@retnag and others:

Table uses a memoized computation pipeline for it's row model. This means that if any part of the pipeline is invalidated, all of it's dependents are also invalidated. So for example, when you change the data, the row model, filter model, sorting model, grouping model, pagination model etc will also need to be recalculated.

The primary reason for this is that we don't really know what changed when the core data model changes, since that's in your control, not the libraries. So, we assume the worst, that the entire underlying data model has changed. I haven't really found a good way around this without bloating the library into some kind of excel-like graph system (see AG Grid), which would allow for more robust fine-grained dependency tracking and computationally efficient updates.

The best tips I have for you:

• If you are changing the actual underlying data, consider that this could affect the sorting, filtering, etc of the table and side with accuracy over efficiency
• If you are changing data that doesn't affect the data model pipeline, then store that data in a parallel structure (or on the structure itself, but in a mutable way that won't affect table's change detection) and rely on your framework's normal state/rendering strategy for updating the cells with that new data.
• Slim down your data, or handle the computationally expensive stuff on the server (or just on another thread). This is probably the easiest and most elegant solution, but you may resent it the most 😉

[pdela]

I have the same unresponsiveness problem in angular and with just few dozen of rows while sorting or filtering, etc.
I'm curious to know if moving all these computations to a web worker would be feasible?
How can this be achieved? Can it be done from the consumer of the library side in your opinion?
Unfortunately I guess the best solution would be to have the library itself create a web worker to run all the computations and provide a way to signal the consumer when the computations are in progress so to update the UI with a loader of some sort.
What do you think about it(

[retnag]

thanks for the quick and detailed reply! <3