Vue Loop – Infinite scrolling

scroll-past-top - default: false, scroll-past-bottom - default: true

this will allow the user to either scroll loop from bottom, top or both :)

Thanks for the feedback. Update coming soon.

The ultra annoying thing is that in Safari Reading List, scrolling "past the end" of a page takes you to the next item in your Reading List. So Quartz breaks that feature...

On (desktop) Safari hovering over a few sections causes the site to just randomly scroll to another section (e.g. Hovering any of the first 2 links of "Get in touch" goes a section back and the third one goes to the last hero section").

In mobile Safari (latest version) the website stops functioning after the first scroll until the end, the hero is the only thing that is viewable.

Lastly, the infinite scrolling loop doesn't work backwards (i.e. scrolling up) which gets a bit confusing.

There's something extremely fundamental in scrolling, it gets embedded in the user's cognition. I wonder what we need to do to raise awareness in finally stopping to meddle with it.

Anyway: this looks like a failed experiment to me.

Next!

I've investigated the problem on a VueJS app which rendered a live-updated table-like DOM with thousands of rows, and was quite slow in rendering and scrolling, especially on mobile. For my use case the easiest solution was to render the first X elements, on-the-fly render the next elements as you scrolled down and disable the VueJS watching and reactivity logic for the DOM elements outside the viewport, so that when you scroll back up the elements are still there and you do not spend too much time recreating them (the DOM is slow).

I had to use unexported, private VueJS methods, I raised an issue on Github asking them to provide public hooks but it was declined.

This method works when you have a big but not huge list. In the latter case the bottleneck is not your JS framework but the browser, so yeah, you should delete and create DOM elements on the fly.

(I'd share my code but it's on a commercial app, and a huge hack that I'm surprised I've managed to make work.)

Yes, and these are the only implementations anyone should ever use. You have to remove the DOM elements for rows above and below the viewport (+/- headroom for a couple of rows). When you do so, you use only two placeholder elements to replace the scrollable height of the removed items (one above the viewport, one below).

Any other solution breaks scrolling expectations and/or uses too much memory, which will crash mobile browsers (particularly on iOS). An infinite scroll library is not a 1-day project. It takes a lot of mindful effort to do properly, and nearly every library author takes shortcuts that don't take these requirements into account on their first release.

Working on solutions using touchmove etc.

Thanks!