-
Notifications
You must be signed in to change notification settings - Fork 290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When using variable row heights, setting scrollTop
doesn't work well. Fix proposed
#700
Comments
Hey @cristian-spiescu , thanks for filing this in a very detailed manner! 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. 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. Some immediate questions for the PR:
|
My colleague Daniela has submitted the PR #701. We have implemented a cache logic. Now on every |
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. Summary: Incase the cached row height needs to be reset, the new public API |
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
:The text was updated successfully, but these errors were encountered: