New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Infinite scroll “shortcut” makes unnecessary and erroneous AJAX requests #384
Comments
@JosKrause Just letting you know that I see the behavior you're describing and will try to track down a cause when I can. If you learn anything new yourself in the meantime, please let me know. |
I'm having the same problem. I tweaked the infinite shortcut a bit to fit my specific use case, but every now and again, multiple requests will be made immediately, one after the other. It's tricky to debug and haven't figured out the issue yet. Did either of you make any headway? |
Here's my code. I tested with the original against mine. Original code starts duplicating loaded content. Especially when you've scrolled alot and do a refresh in FF. FF wants to scroll to the same position and thus loads waypoints wildly. My script has no problems with that and continuing to scroll works as expected. I tested with two Strips of content. Each strip was only 200px high so that many loads can happen since many strips fit on the page simultaneously, all darning an infinite-more link.
''' |
@ProGFB thanks for posting this. But somehow your changes make it so that it loads the second page, but then it won't load the third page and it keeps my more link visible. No errors in the dev console. |
do you have a test link? Maybe your more-link in the loaded content isn't correctly placed. |
@ProGFB I'll check that |
@ProGFB it looks like the issue with your script is this line:
I'm using bootstrap navigation and it moves my next link out of the Markup:
After the first request it looks roughly like this:
|
I am having a similar problem. If I zoom my browser window to 50% two additional XHR request with the exact same url are issued on the first page load. I would assume that one is enough. When I start scrolling then three XHR requests are send one first scroll triggger and seven on the second scroll trigger. Here are the callstacks from Chrome's network tab of the first two XHR requests. The second request might be more interesting because it is superfluous I would guess. (jquery is 2.1.4, js files are uncompressed): The callstack of the first XHR
The callstack of the second XHR:
|
All I can contribute is that my changes have fixed the problems for me here: http://berglust.at/de/start |
I had the same issue and expanded the Waypoint.Infinite class as follows: var infinite = new Waypoint.Infinite({ This way, the link to the previous content is removed before adding the new url, meaning it can't be called anymore. Solved the problem for me for most cases. I did have one page where I still had the issue, but when I increased the fetch size of the query it was gone. |
I came across this bizarre issue while working for a client today. This is how I solved it. Relevant changes are commented.
If you've ended up at this page as baffled as I was when I first saw this behavior then I hope this helps to save you some time. |
Hello! I've just tested quickly what @vjong said and later on @besworks' solution, and neither of them seemed to work for me. @vjong's solution have kept the problem and @besworks have loaded just the first next page, disconsidering the others. I'm still looking for a solution to the problem. Thanks for the contribution anyways, guys. Regards. |
My waypoint solution is still working strong: |
Hello! I have done some testing this morning, and I may have found a way of fixing the bug. It may be not the must clever way, but it has worked. When I was trying to check ...
/* Private */
Infinite.prototype.setupHandler = function() {
this.options.handler = $.proxy(function() {
// console.log('setupHandler is called... this.$more[0] = ');
// console.log(this.$more[0]);
// console.log('----------');
if ( ! $.contains(document, this.$more[0])) {
// console.log('Element is detached');
this.destroy();
return;
}
... It seemed to have solved the problem. The way I was testing, was, being in the middle of the pages (after there were loaded asynchronously) and refreshing the page, on Google Chrome 44.0.2403.130 m. Hope to help anyone to implement a bug fix to this code somehow. I'll also be opening a pull request if the author @imakewebthings want to merge it to the code. Best regards! |
I too found issues with my solution. I gave the suggestion from @giovannipds a try and it was better but I was getting duplicates from the last page of content appearing if I reached the end of the content and reloaded the page. I did some more digging and discovered that the Infinite.prototype.destroy method didn't seem to really be destroying anything... I have come up with a new solution that really seems to solve everything. Starting with a fresh copy of https://github.com/imakewebthings/waypoints/blob/master/lib/shortcuts/infinite.js change line 68 from: Voila! Everything now works as expected. You can see a working demo at http://dev.besworks.net/test/infinite/ |
Thank you everyone for your patience and many investigations. I'm working on getting this sorted this weekend. |
Hello Caleb (@imakewebthings)! Any updates on your progresses? Didn't tried @besworks's tip yet, but seems to be a smarter solution. Thanks for the contribution. :) Cheers! |
@giovannipds Yes, I tracked down the cause. @besworks' last comment was very close to the root of the problem. I'll try to explain the bug and how I intend to fix it. When the waypoints/lib/shortcuts/infinite.js Line 25 in 13ae054
When a Waypoint is initialized, it immediately checks to see if it has already been crossed and triggers the handler in the "down" direction. As everyone has noted, this is where the bug appears, when the page is already at a point where it needs to load new content when waypoints/lib/shortcuts/infinite.js Line 33 in 13ae054
The problem with waypoints/lib/shortcuts/infinite.js Line 67 in 13ae054
What held me up from committing a fix last weekend was deciding how best to tackle this, and I've reached a conclusion that will end up killing two birds with one stone. All of those initial trigger checks during Waypoint instantiation will be no longer be synchronous. They will be delayed until the next I anticipate this will break exactly zero real world uses of Waypoints but it is going to be a fundamental change to the behavior and will be a bump in major version to 4.0.0. Expect that this weekend. |
Please give this a try with 4.0.0, everyone. |
I'm having this issue on 4.0.0 --- edit |
I am having the same problem with 4.0.1. When the first page is called, it subsequently calls every other page till the end. Only occurs when I have and "offset" value. CAN be either integer or percent, positive or negative.
|
Note: This issue is registered upon request from stackoverflow here
Note: I am not the writer of that stackoverflow question, however I am repeatedly running into this issue, so I am creating this issue to give it visibility and hopefully a quick resolve, thanks.
Running into a problem while trying to implement Waypoints infinite scroll example from http://imakewebthings.com/waypoints/shortcuts/infinite-scroll/.
Here is a JSFiddle to demonstrate my issue: http://jsfiddle.net/jmankin/75g6cap2/5/
HTML
JS
In instances where the 1st "infinite-more-link" is "above the fold" of the viewport on page load (i.e. the "inifinite-item" content is too short to require scrolling), the script correctly makes an AJAX call to the link href and loads the requested content.
However, it then prematurely--and seemingly incorrectly--proceeds to make the AJAX call to the 2nd "infinite-more-link" even though that is "below the fold" when it loads.
Secondly, from then on, scrolling to the bottom of the page (what would technically now be the 2nd "infinite-item" content element) will cause an AJAX call to the originally requested URL (the one that the client explicitly addressed), which is completely baffling. Under normal circumstances, it does this over and over again. In jsFiddle, it just does it the once, but that still gives you an idea of what I mean.
(Note: I'm not able to know ahead of time the length of the content I'd be loading, which is why I can't guarantee that the user will have to scroll down to see the 1st "infinite-more-link.")
The text was updated successfully, but these errors were encountered: