schrodinger / fixed-data-table-2

A React table component designed to allow presenting millions of rows of data.
http://schrodinger.github.io/fixed-data-table-2/
Other
1.29k stars 289 forks source link

When using variable row heights, setting `scrollTop` doesn't work well. Fix proposed #700

Closed cristian-spiescu closed 10 months ago

cristian-spiescu commented 1 year ago

Current Behavior

We have created a sample where we have variable row heights provided via rowHeightGetter property: first row height = 30px and the rest of the rows height = 500px, cf. here. rowheight property = 30.

When the scroll button is pressed (scrollTop changes from 0 to 5000), the first row displayed is being 41. This is wrong. The correct value is 11: because 1 (i.e. the first row) x 30 + 9 (the following rows) x 500 = 4800.

Possible Solution

This happens because the rowHeightGetter is not invoked several times, in order to inspect the custom height of each row.

Our fix

We have done the following modification. Not knowing if this has a big performance impact, for the moment we also added a flag to enable/disable it.

Screenshot, before the fix

image

Screenshot, after the fix

image

Questions

1/ Before submitting the PR, we'd like to hear if there are preliminary thoughts. 2/ The flag: should we keep it? Or remove it and always apply the new behavior? We don't know how to benchmark the performance impact. A "manual"/subjective evaluation of the samples w/ a lot of data, doesn't seem to show degraded perf. 3/ Do you think we should also include (in the PR) the example we created?

Context

We work on a Gantt component:

image

On the right, our component. On the left: your component. The main use case is to synchronize the heights of the rows and scrollTop:

pradeepnschrodinger commented 1 year ago

Hey @cristian-spiescu , thanks for filing this in a very detailed manner! The context behind the issue, example/code changes, and screenshots have been very helpful 😄 .

FDT calculates row heights lazily, so the offsets for the currently visible rows at any given point of time will be inaccurate until all the row heights of the previous rows are calculated. This was a design decision focusing around lazy loading data and maximising performance against huge:no of rows with moderate sacrifices to offset accuracy.

As you noted, this doesn't work out well when scrolling to an arbitrary offset and expecting it to match with other scrollable containers.

I think having some way to make FDT obey accurate offsets will be awesome. Please put the PR in. We can continue the discssion there.

Some immediate questions for the PR:

cristian-spiescu commented 1 year ago

Hi @pradeepnschrodinger,

My colleague Daniela has submitted the PR #701. We have implemented a cache logic. Now on every componentDidUpdate() a new loop for calculation IS NOT made, as in the initial commit. We are waiting for your feedback.

pradeepnschrodinger commented 1 year ago

Nice, thanks! We'll checkout the PR with the devs sometime next week.

cc: @AmanGupta2708, @karry08, @abhisheksingh2410

pradeepnschrodinger commented 10 months ago

Released the fix for this issue with v2.0.5 via #701. cc: @daniela-mateescu, @cristian-spiescu, thanks for your contribution!

Summary: The new optional table prop isVerticalScrollExact (defaulted as `false) can be turned on to use precise vertical scrolls in FDT. This works by making FDT fetch row heights for ALL rows in the table. There's also an internal cache so that FDT won't keep re-requesting all rows on every render.

Incase the cached row height needs to be reset, the new public API updateRowHeights(rowIndex) can be used to reset the row heights starting from rowIndex until the end of the table.