startReached called multiple times
See original GitHub issueWhen the response to prepend new items to an inverse list takes less than about ~200ms, there is a chance that startReached will get called multiple times. Visually this causes the scrollbar to flicker. Behind the scenes, another startReached callback is fired, and more data is loaded.

Check out this repo to investigate. It’s much easier to reproduce locally than on codesandbox.
Edit:
My current workaround is to check if
This approach doesn’t work as more data is still loaded, just later.startReached was called within the last 200ms; and, if so, then wait before fetching. This isn’t an optimal solution as it doesn’t work 100% of the time and the user shouldn’t have to wait unnecessarily because of fast responses.
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (3 by maintainers)
Top Results From Across the Web
Why is my component in React being called multiple times?
I am having an issue where my Listings component is running twice and I only want it to run once. I tried adding...
Read more >Virtuoso API Reference
Called with the new set of items each time the list items are rendered due to scrolling. react18ConcurrentRendering#. • Optional react18ConcurrentRendering: ...
Read more >Novell Documentation: NetWare 6 - Search Parameters
You can specify more than one ID by using the same field name more than once. ... The example shows the number of...
Read more >Cricket-Malan one short of ton as England secure ... - Reuters
South Africa elected to bat after winning the toss and, after a spluttering start, reached 191 for three wickets.
Read more >ms_mascotresults - Matrix Science
virtual int, findProteins (const int startHit, const std::string &str, ... Call this function multiple times for each masterHit, incrementing id each time.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

This is tricky, I think the changes applied in the commit above affect it, but even with them, I managed to reproduce the issue every once in a while in Edge / Win10. Chrome seems to be better.
Windows browser scroll kinetics gives me a horrible headache. The root cause of the problem is that the Windows engines discard
scrollBycalls if the user is currently scrolling - this prevents the readjustment of the scroll location.I recommend that you debounce the loading logic further up to your case to play it safe.
Hope this helps. I hope that I can figure out more reliable scroll compensation for windows at some point, but that’s the best I can come up with for now.
Yes. I checked the api endpoint as well and saw 2 requests. Also, the 2nd request is not just the first request being sent twice. The 2nd request is asking for the next batch, so it’s being called after the first request’s data is loaded.
Yes.
Here are my findings for reproducibility:
It appears to occur more frequently if you slow the scrolling down as you approach the top.