Vue Loop – Infinite scrolling

[steinuil]

This just looks like bad UI to me. On my desktop browser I often press End to get somewhere near the end of the page, here if you do that it just goes back up.

If I accidentally scroll to the end while reading something I can't scroll back up, I'll have to scroll down to the end and hope I don't scroll too far and trigger the loop again.

[JosephSmith127]

I am planning on adding two new props to the component

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.

[leokennis]

What's even more annoying are sites like Quartz, where if you scroll to the bottom it will load some additional headlines. When you scroll past these, more are loaded. It's a page without an end.

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...

[conradk]

I tried viewing the Look Studios website on Firefox, scrolling down with the touchpad. The website skips over some content sections and once I get to the page footer, the page suddenly scrolls extremely slowly. To the point where it looks like my browser crashes every time I reach the bottom of the page.

[vmasto]

Indeed, the website seem fairly broken. i.e. the right side is clipped as well on Firefox (can't see the Contact link on the mast head).

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.

[hatsunearu]

This is the worst website scrolling nonsense I've ever encountered. Wow.

[lelandbatey]

After messing about with the Look studio page, I learned that they have a "force scroll to next session" bound to clicking. As it turns out, when using two finger scroll I frequently click, causing the page to leap around like you described.

[bartl]

I see the same thing except with no crashes.

Anyway: this looks like a failed experiment to me.

Next!

[Xoros]

I tried the live demo on Safari on iPhone. When it arrives to the end (with the logo) it's starts flickering around 10 times. Then you can continue scrolling.

I don't know if it's on purpose (distracting effect while doing your stuff). But it's more looking like a bug.

Despite that, works like a charm.

[JosephSmith127]

This is due to the fact that on mobile devices the scroll event is triggered when you've released your finger. Unlike web which is during the scroll. I am working on a fix for this now!

[NinoScript]

And it flashes indefinitely if you don't release your finger

[aleksandrm]

Title is a bit misleading, this is not an actual infinite scrolling as we generally know it by, but a looped scrolling, as the name suggests.

[scottmf]

Ironically it is actually infinite.

[yourapostasy]

Are there implementations of infinite scrolling that delete DOM elements outside of a specified range of the viewport? Then the scrolling still appears responsive to within X pages of scrolling from the current viewport, but any pages beyond that range are actually inserted in on demand when the viewport moves towards them, saving browser memory at the cost of bandwidth and computational time on both the browser and server sides.

[1_player]

Perhaps react virtual list (https://github.com/developerdizzle/react-virtual-list) ?

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.)

[developer2]

>> Are there implementations of infinite scrolling that delete DOM elements outside of a specified range of the viewport?

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.

[JosephSmith127]

Thanks for all your feedback! I'll be taking it all in and making some improvements today! Expect an update to the repo and package soon ️

[thesmallestcat]

Not debouncing the scroll action seems like a pretty poor idea. This could use some optimization for sure. Also, not hugely important, but my OCD hates that the source code has several misspellings and inconsistent use of const/var/let. A little confused why you're using useCapture = true in the addEventListener call. Neat CSS, I learned a couple things.

[duke360]

just a little heads up: it looks shitty on a logitech free-wheeled mouse

[neotek]

But... why?

[omnimus]

why not? interaction design studios are always looking for some nice fun spin on mainstream traditional design

[peterc1731]

Works like a dream for me in chrome, seems like a nice way to make a simple static site feel a bit more individual and interesting. nice job.

[penpapersw]

Hmm, if you get near the bottom and then resize your window smaller, it doesn't "jump" back up to the top.

[junnan]

This actually looks really nice in my android chrome. It might be useful in some cases.

[JosephSmith127]

Thanks for the feedback. Thats good to know, I know with ios it stops DOM manipulation until after the scroll event has been finished, hence why we're getting the flashing issue. I can fix this by taking away the -webkit-overflow-scrolling: touch; issue is then the scrolling isn't smooth.

Working on solutions using touchmove etc.

Thanks!

[homulilly]

I'm in chrome and uh, this doesn't seem to actually do anything?

[petters]

Works well for me on mobile Chrome. But loads way too slowly.

[jazoom]

This is pretty cool

[geraldchecka]

Really liked the idea. Good one.