search

lizmat / App-Raku-Log

Cro application for presenting Raku IRC logs
Artistic License 2.0
3 stars 3 forks source link

Implement smoother infiniscroll #12

Closed patrickbkr closed 3 years ago

patrickbkr commented 3 years ago

By keeping the position of the content fixed on the screen.

Fixes #9

@lizmat Please do test this PR prior to merging. I did not set up the App-Raku-Log server on my side, but just monkey-patched the respective functions in the browser for testing.

lizmat commented 3 years ago

I think https://github.com/lizmat/App-Raku-Log/commit/8586ac13254b47913a0f4326a39e0e93bd42adde implements what you want. Please close this PR if you think that's correct :-)

lizmat commented 3 years ago

BTW, https://github.com/lizmat/App-Raku-Log/commit/8586ac13254b47913a0f4326a39e0e93bd42adde is live now.

patrickbkr commented 3 years ago

Yes, that's pretty much how I intended it to work and it works for me. Thanks!

One question though. The change of if (window.scrollY == 0) { to if (window.scrollY < 100) { was intentional, so as to not "bump" into the top, but load more lines a bit sooner. Is there a deeper reason you kept the == 0 bit instead?

lizmat commented 3 years ago

@patrickbkr Yes, there is a deeper reason: you could have 2 or more events scrolling up before the first event finished its work. Which would mean duplicates.

It is a bit of a hack, as the current situation would only make that much less likely to happen, but not impossible. Guess I need to introduce a flag: "getting scrollup info now".

lizmat commented 3 years ago

https://github.com/lizmat/App-Raku-Log/commit/9ac3aea2fd46458d689a836be1fdebe33b6d4391 enables the logic you wanted. It works nicely!

patrickbkr commented 3 years ago

@lizmat Thank you!

Also thanks for explaining the difficulty with the early loading. Yes, I see how this can fail. Let's see how soon a report about duplicate loads will trickle in...