Attaching handlers to window scroll event [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 1 year ago.

Improve this question

John Resig suggests using setInterval() in order to reduce the number of times the handler is called - see http://ejohn.org/blog/learning-from-twitter/

John's solution from the blog post:

var outerPane = $details.find(".details-pane-outer"),
    didScroll = false;
 
$(window).scroll(function() {
    didScroll = true;
});
 
setInterval(function() {
    if ( didScroll ) {
        didScroll = false;
        // Check your page position and then
        // Load in more results
    }
}, 250);

Can invoking a continues interval really be a sensible idea?

Would Michael Jackson's approach makes more sense as it doesn't mean we're co开发者_开发技巧nstantly polling?

Michael's solution from the comments:

var timer = 0;

$(window).scroll(function () {
  if (timer) {
    clearTimeout(timer);
  }

  // Use a buffer so we don't call myCallback too often.
  timer = setTimeout(myCallback, 100);
});

Can anybody share any advice / opinion?

---

I was reading the same post, but ended with some mixed aproach.

Neither Jhon Resig nor MJ were fine to me. although I really apreciate the light they put on my research

Here is my code, which is executed as soon as the event is fired, but run only once every 250ms, when it is "re-enabled"

var scrollEnabled = true;

$(window).on('scroll', function(event) {
  if (!scrollEnabled) {
    return;
  }
  scrollEnabled = false; 
  console.log('i am scrolling');
  return setTimeout((function() {
    scrollEnabled = true;
    console.log('scroll enabled now');
  }), 250);
});

---

John Resig's approach is the most sensible. The scroll event gets dispatched ALOT in most modern browsers. For a quick scroll action of only 50px on the y-axis, it could be dispatched 20-30 times. If you have a handler being invoked during each of those events, you'll lock up the UI thread and scrolling with be jerky (as John points out).

Also, keep in mind that a quick function being executed every 50ms is not a big deal in modern browsers. That is a function invokation every 5 or 6 frames. What you are trying to avoid is a function invokation on every frame, which is what occurs if you use the scroll event.

Edited

Oh sorry, I missed that comment when I posted the first version (I only searched the post for MJ's name not the comments). Rate limiting the scrollEvent handler is a smart approach +1. I actually like it more than Resig's strategy because you'll always get the first scroll event when it happens and then limit each other scroll event thrown after it to a maximum of once for every 100ms.

With Resig's approach, you could be delayed up to 100ms before your callback is notified of a scroll event. The 100ms delay could be perceived as a sluggish interface by heavy users.