[Perf]: Infinite Scrolling with just-in-time data fetching and virtualization

[MihirGH]

Hello,

First of all, props to all the folks who are currently contributing and maintaining to this wonderful headless hook based functionality and Tanner for the amazing react-virtual hook.

I am trying to implement infinite scrolling along with virtualization and I wanted opinions about what can be some of the best practices when using react-table for the case of infinite scrolling so that there is no major impact on performance.
I know numbers and measurements are important when discussing about perf but I haven't been able to measure the performance in my original app which renders ~35-40 columns and has records in tens of thousands. Hence I am more worried about performance. Also, sorry if the discussion is kinda vague without numbers.

Here is the simple sandbox that I have made for the sake of discussion: https://codesandbox.io/s/eloquent-ishizaka-56017
We rely on react-virtual to let us know whenever the items in the viewports have changed so we make a request and fetch data accordingly.

I have two doubts regarding how to best use useTable with infinite scrolling:

1. So, currently whenever the user scrolls the table, I decide the page and fire off a network request asking for the data for that particular page.
   Now, once the data finally loads, I combine it with the existing data and then pass the new concatenated array as data to the useTable.
   This causes the rows to be recomputed.
   Even if I cache the results of prepareRow since the rows are same just that the reference has changed because of new data, the cache will break for older rows and my cells would re-render. For my original use-case, the cell renderers are pretty heavy and the re-render is expensive.
   I haven't tried React.memo but not sure if that can save me from re-rendering if the row itself changes (I am guessing the value returned from the accessor would also be a new reference?).
   Also, consider that user has already scrolled down to ~400 to 500 rows. Now the re-calculating of new rows would be over those already scrolled down rows too, making the time spent in calculating rows variable and probably high as user scrolls down.

2. For the case of inline edit where just one cell of one row in the whole data array has changed, the re-computation of rows seem like an overkill considering there can be many rows if user has scrolled down.

One solution to this (along with caching results of prepareRow) that I've been thinking is: Keep a fixed number of rows in data and change that data based on the scroll ( rows based on viewport + overscan number of rows on both upper and lower side). This would make sure that we're always re-doing almost a fixed number of iterations to compute rows whenever data changes.

I am not sure if there are any other best practices that can be used here.

Feedback is much appreciated

Thanks in advance!