3 ms·
I'm working on a photo organizer for my family's photos which has about 115K entries. I want all of these to be visible in a single pane, so I implemented what
by jewel 12y ago
I'm working on a photo organizer for my family's photos which has about 115K entries. I want all of these to be visible in a single pane, so I implemented what I call "near-infinite scrolling". It could also be called "transparent pagination".
It avoids the issues of infinite scrolling really well. What you do is have a very tall div, say 8 million pixels. Inside of that you add a div that you move around as the page scrolls, let's call it the viewport. Whenever there is a scroll event, you check and see if the viewport is no longer visible on the screen and then repopulate its contents.
This is indistinguishable from a very long page as far as the user is concerned. You can grab the scrollbar and jump halfway down. You can hit the "END" key and jump all the way to the end of the results. If you scroll faster than content can be loaded, scrolling doesn't suddenly stop when you reach the end of the loaded content, then have the content appear and have to start scrolling again.
The back and forward buttons work as expected, at least in all the browsers I've tried. Refresh does too. This doesn't require any extra work on my part. The browser goes back to the page and sets the scroll position correctly, which fires an onscroll event. This is then treated like a normal user scroll, which will cause the viewport to be moved and the necessary information to be drawn.
In my case it's a grid of square images so the math is straightforward. I load three extra rows above and below what is visible in the viewport.
Unfortunately, I don't have a demo available in a public place. I've implemented this in jquery, then again in ember, then again in react (as ember was too slow). I'm working on getting it working with the ember glimmer branch. If you're interested in looking at my broken code, it's at https://github.com/jewel/hypercheese https://github.com/jewel/hypercheese.
If you are using infinite scroll to replace pagination, please consider using this technique.
Edit: SlickGrid has something they call "virtual scrolling" that appears to be using a similar technique. Here is a spreadsheet with 500,000 rows: http://mleibman.github.io/SlickGrid/examples/example-optimizing-dataview.html http://mleibman.github.io/SlickGrid/examples/example-optimiz...
- xanderstrike 12y agoWhat problems of infinite scrolling does this solve? Sounds to me like you've just implemented it in an unusual way.
- devmach 12y agoOne possible downside of this technique would be searching in previous "pages" would be difficult / impossible. Since element is removed once its out of view port, browsers' search function can not find given text. Although it should be acceptable if you have only images.
- tangent128 12y agoI used essentially the same technique when coding an alternate reader for a long-running webcomic[1][2] With use of url hashes, you can even deep-link to specific scroll positions, allowing links to be shared sanely. As you have to know the dimensions of each "page" upfront to keep the scrollbar honest, I think this technique fits better with image-based content; textual content can have unpredictable flowing with different browser fonts, plus as siblings have noted it breaks ctrl-f. [1]: http://tangent128.name/depot/toys/freefall/freefall-flytable.html#1 http://tangent128.name/depot/toys/freefall/freefall-flytable... [2]: https://github.com/Tangent128/freefall-speedreader https://github.com/Tangent128/freefall-speedreader