When using variable row heights, setting `scrollTop` doesn't work well. Fix proposed
cristian-spiescu opened this issue · 4 comments
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
Screenshot, after the fix
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:
On the right, our component. On the left: your component. The main use case is to synchronize the heights of the rows and scrollTop
:
- on scroll in Gantt
- on scroll in Table
- on expand an item
- on programmatic scroll
- etc.
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:
- Could you test
exactScrollTopInCaseOfVariableRowHeights
with controlled scrolling?- Controlled scrolling is a typical use case in FDT where the scroll offsets are kept continously in sync with FDT via scroll handlers like
onVerticalScroll
(See AutoScroll example). - I expect FDT will preload the heights of all previous rows on EVERY render in this case.
- This could be expensive for really large tables, especially if we need 60fps renders.
- Controlled scrolling is a typical use case in FDT where the scroll offsets are kept continously in sync with FDT via scroll handlers like
- Should we employ a cache (or something to skip previous fetches) for performance?
- If we do, then we'll need to figure out how a user can invalidate the cache (i.e, update row heights later) ?
- eg: react-window has a similar use case and their design is to expose an API method to let the user manually clear the cached size of a specific item, causing the container to rerender and refetch data after that item.
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.
Nice, thanks! We'll checkout the PR with the devs sometime next week.
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.