Присоединение обработчиков к событию прокрутки окна

Question

Джон Резиг предлагает использовать setInterval (), чтобы уменьшить количество вызовов обработчика - см. http://ejohn.org/blog/learning-from-twitter/

Решение Джона из поста в блоге:

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

Может ли использование продолжающегося интервала действительно разумной идеей?

Подход Майкла Джексона имеет больше смысла, поскольку это не значит, что мы постоянно проводим опрос?

Решение Майкла из комментариев:

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);
});

Кто-нибудь может поделиться каким-либо советом / мнением?

Rich

Answer 1

Я читал тот же пост, но закончил со смешанным подходом.

Ни Jhon Resig, ни MJ не были в порядке со мной. хотя я действительно ценю свет, который они освещают мои исследования

Вот мой код, который выполняется, как только событие запускается, но запускается только один раз каждые 250 мс, когда оно «повторно включено»

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);
});

Answer 2

Подход Джона Резига самый разумный. Событие прокрутки отправляется ALOT в большинстве современных браузеров. Для быстрого действия прокрутки по оси Y, равного 50 пикселям, его можно отправить 20-30 раз. Если у вас есть обработчик, вызываемый во время каждого из этих событий, вы заблокируете поток пользовательского интерфейса и прокручиваете его с рывками (как указывает Джон).

Кроме того, имейте в виду, что быстрая функция, выполняемая каждые 50 мс, не имеет большого значения в современных браузерах. Это вызов функции каждые 5 или 6 кадров. Чего вы пытаетесь избежать, так это вызова функций в каждом кадре, что происходит, если вы используете событие прокрутки.

Отредактированный

Извините, я пропустил этот комментарий, когда выложил первую версию (я искал в сообщении только имя MJ, а не комментарии). Ограничение скорости обработчиком scrollEvent - разумный подход +1. На самом деле он мне нравится больше, чем стратегия Ресига, потому что вы всегда получите первое событие прокрутки, когда это произойдет, а затем ограничите каждое событие прокрутки, выбрасываемое после него, максимум один раз за каждые 100 мс.

При подходе Resig вы можете отложить до 100 мсек, прежде чем ваш обратный вызов будет уведомлен о событии прокрутки. Задержка в 100 мс может восприниматься тяжелым пользователем как медленный интерфейс.