We currently render the whole table which gets sluggish when there's a lot of participants (10k+).
The list now uses infinite scrolling instead which makes it much more responsive.
Additionally, we normally preload all data from IndexedDB before switching to a new page (e.g. when navigating to a regform). With a large participant list, this introduces a visible lag when preloading all participants from the DB. I changed it so that the participants are loaded after the page is loaded. Note that, short participant lists will never see a difference since they are fast to load anyway.
Made <ScrollRestoration /> work with the participant list i.e. when coming back from a participant the scroll position is restored - not as straighforward due to the infinite scrolling and the fact that we don't use a data loader here.
Scrollbar height remains constant as more participants rendered via infinite scroll (uses a placeholder with the same height as the full list)
Deployed here: https://indico-checkin-test-2.app.cern.ch/
We currently render the whole table which gets sluggish when there's a lot of participants (10k+). The list now uses infinite scrolling instead which makes it much more responsive.
Additionally, we normally preload all data from IndexedDB before switching to a new page (e.g. when navigating to a regform). With a large participant list, this introduces a visible lag when preloading all participants from the DB. I changed it so that the participants are loaded after the page is loaded. Note that, short participant lists will never see a difference since they are fast to load anyway.
More UX improvements based on feedback:
<ScrollRestoration />
globally<ScrollRestoration />
work with the participant list i.e. when coming back from a participant the scroll position is restored - not as straighforward due to the infinite scrolling and the fact that we don't use a data loader here.