scrollToIndex and dynamic size

[sm2017]

I have a dynamic height list and want to scroll to end
https://codesandbox.io/s/exciting-kate-h555x?file=/src/index.js

When I press Scroll To end it sometimes goes to the end and sometime to the Row 9993
Please open the list and press Scroll To end , If you goes to end refresh the page and retry again

[piecyk]

It's happening because when scrolling also size of item is read, we try to solve it via calling scrollToIndex two times, https://github.com/tannerlinsley/react-virtual/blob/master/src/index.js#L286-L295

Using rangeExtractor we can know what elements are actually in viewport, you can try something like this https://codesandbox.io/s/toend-s53zp

[sm2017]

@piecyk Nice job! , but I do exactly same in my project ( a chat application), it's not working there

[sm2017]

It's a log in the new scrollToIndex

isVisible true
start 6
index 21
end 21

but the scroll is not in the end position

[sm2017]

@piecyk I dont know why, But If I remove your solution with rangeExtractor in my project and call rowVirtualizer.scrollToIndex with setTimeout(...,1000) it works well, always and in the first call

[sm2017]

@piecyk you have two requestAnimationFrame in your new scrollToIndex , I don't know why! can you explain?
If I add two more requestAnimationFrame the code works in my project too

Why should I have 4 requestAnimationFrame? why not 5? why not 1?

[piecyk]

@sm2017 it's a timing issue, let's explain first what is happening in context of dynamic sizing

• trigger scrollToIndex(n)
• scroll jumps to n, as we didn't render any of those element it's size is k, visible range is calculated based on that size so index is visible in viewport
• now measureRef is called, that will update size of each element and shift visible element a bit, base on how it's differ from default size k
• also in same time we call requestAnimationFrame with again call scrollToIndex, here we hope that all the elements have been measured

you have two requestAnimationFrame in your new scrollToIndex, I don't know why! can you explain?

Having two, delays the scrollToIndex after all the elements have been measured in this example.

If I add two more requestAnimationFrame the code works in my project too
Why should I have 4 requestAnimationFrame? why not 5? why not 1?

Looks like your elements are more expensive and take more time to update size, that's why having setTimeout 1000, like in your example will jump to correct place as in most cases everything was measured.

const scrollToIndex = (index, ...args) => {
  rowVirtualizer.scrollToIndex(index, ...args);

  setTimeout(() => {
    const { start, end } = rangeRef.current;

    const isVisible = index >= start && index <= end;

    if (!isVisible) {
      scrollToIndex(index, ...args);
    }
  }, 1000);
};

Using setTimeout has it's own issues, as how guess the magic number for delay, bigger number will add extra jump.

More robust solution would be to check if we have any pending measurements in place, and till then defer the next call of scrollToIndex.

[piecyk]

I think this #217 should help a bit as range is calculated now in same render as measurements. Furthermore maybe we can check if all pending measurements are done, but it's not that strait forward 🤔

[sm2017]

@piecyk Thanks a lot
Just want to ask Is it ok to have 4 requestAnimationFrame?

[piecyk]

Just want to ask Is it ok to have 4 requestAnimationFrame?

It's definitely a code smell and would not recommend it, but if it solve the issue 99% of times 🙈

Don't know exactly what is your use case, but there is also an option to pre-render the last n elements of list, just make it render once before scrolling. It can be done via rangeExtractor, for example pre rendering 25 last items https://codesandbox.io/s/toend-forked-mvow4?file=/src/index.js

[sm2017]

@piecyk thank you very must
The latest approach is not working in my project, I have a chat application, the scroll is inverted and the latest message exists always, when scrolling to top we must fetch more messages and keep the scroll position
Sometime I must scroll to the end of chat, i.e. When we click to another room or new message received

The latest approach is not working because the latest message is rendered always as pre-rendering has no effect, meanwhile we fetch new messages and must scroll to last message preserve scroll position

the 4 requestAnimationFrame solve issue but make some unexpected behavior in another parts of the code, I think it make some race condition, I see that I have some infinitive scrolling to an index when I scroll to the top to fetch more messages

@piecyk Thanks a lot for your time

[vincentbello]

@tannerlinsley how come this issue was closed? as far as i can tell, this is still a bug without a reliable workaround. here is a simple repro.

[tannerlinsley]

This seems to be working in v3 beta, but might still be an issue under certain circumstances. If it's encountered in the new beta, I'd like a new issue to be opened with a new codesandbox repro. Thanks!