Наверное, правильнее подписываться на скролл единожды, а дальше передавать событие во все активные инстансы блока.

Т.е., как-то так:

BEMDOM.decl('scrollspy', {
  onSetMod: {
    'js' : {
      'init': function () { this.__self.register(this); },
      '': function () { this.__self.unregister(this); }
    },
    'inviewport' : {
      'true' : function () {},
      '' : function () {},
    }
  },
  _onScroll : function (e) {
    this.toggleMod('inviewport', /* is visible */);
  }
}, {
  _listeners : new Set(),
  register: function (spy) {
    this._listenScroll();
    this._listeners.add(spy);
  },
  unregister: function (spy) { this._listeners.delete(spy); },
  _listenScroll: function () {
    this._bindToWin('scroll', ...);
    this._listenScroll = function () {};
  },
  _onScroll: function (e) {
    this._listeners.forEach(function (spy) {
      spy._onScroll(e);
    });
  }
});

@zxqfox спасибо, сейчас попробую. Я как раз и хотел сделать подписку единожды. Единственно меня смущает this в статических методах...

К сожалению, не получилось. this в статических методах - функция. Следовательно,

this.bindToWin('scroll', ...);

не прокатывает. Так что вопрос с подпиской по прежнему актуален

this в статических методах это сам класс (тож самое, что и this.__self в динамических).

Еще есть вариант:

{
  live : function () {
    $(window).bind('scroll', $.proxy(this._onScroll, this));
  }
}

this в статических методах это сам класс (тож самое, что и this.__self в динамических).

Я лишь имел ввиду, что console.log(this) в статическом методе выдает

 function () {
      return this.__constructor.apply(this, arguments);
  }

Это нормально ;-) У функций тоже есть методы. А функция он только потому, что из него создаются инстансы объекта.

У функций тоже есть методы.

Я далеко не эксперт js, о таком слышу впервые...

Ну, если коротко, то в js все объект:

function Some() {
  this.__self = Some;
}
// эквивалент
var Some = function () {
  this.__self = Some;
};
// и...
console.log(Some.toString); // выведет функцию
Some.prop = 1;
console.log(Some.prop); // 1
var some = new Some();
console.log(some); // объект с __self

Сделай так:

{
  live : function () {
    debugger;
  }
}

И открой в браузере, внутри live дебаггер остановится, и в консольке поиграйся с this.

@kompolom По поводу исходного вопроса топика. Верно ли я понимаю задачу, что на странице есть N блоков, которые должны в момент их появления/исчезновения из вьюпорта как-то реагировать? Если так, то я не очень понимаю, что здесь можно сэкономить. Ведь у каждого блока свои координаты/размеры/реакция на появление во вьюпорте и логично ожидать, что каждый из них сам подпишется. Ну и тормозит же не сама подписка, а обработчик? Но его придется вызывать для каждого блока в любом случае, верно?

Не знаю исходной задачи, но возможно будет полезна библиотека waypoints

@tadatuta Да, задача тригерить события на блоке при появлении/исчезновении.

@tadatuta Ты хочешь сказать что количество подписок никак не повлияет на производительность?

@kompolom Я вижу 2 принципиально разных варианта решения задачи:

1. Есть много блоков scrollspy, каждый из них сам следит за своей видимостью и сам знает, как реагировать на ее изменение. В этом случае экономить нечего.
2. Один глобальный блок слушает скролл и следит за видимостью всех нужных ему блоков. Здесь потенциально может быть какая-то экономия по памяти, но нужно понимать, что в любом случае при каждом наступлении события scroll, потребуется определить координаты всех нужных блоков и запустить реакцию на тех из них, для которых значение изменилось. И именно эта проверка и реакция, а не сам факт подписки, вызывает тормоза.

Я пробовал вариант 1. - не понравилось тормозами. Хочу сделать по второму варианту. Мне кажется так быстрее все же. при этом хочу не вешать этот блок на page а миксовать к тем блокам, которые его реально используют, при этом оставив один обработчик. Насколько я понимаю, это можно реализовать через live события и методы. Примерно как @zxqfox предлагал выше.

Всем спасибо за помощь. Вот что получилось.

Если у кого то найдется время на ревью, буду очень благодарен.

@kompolom

get_offset: function(offset){

Может лучше getOffset?

this.offset = this.params.offset || '10%'; this.scrollin = false;

Я бы приватным свойствам добавил _ в начало.

onScroll: function(){

Как и методам

for (var i in this._listeners) {

без hasOwnProperty в ie будет не айс, я бы пересчитывал единожды и в массив собирал ключи. Операция добавления листенера, вроде как, редкая, а бегать по нему часто.

      if(this.__self.isForward){  // if scrolled down

        if ( (this.oftop <= this.__self.posBottom) && (this.bottom >= this.__self.scroll) ) {

Еще я бы этот кусок переписал как-то иначе. Сложноватый.

В остальном, вполне годно. Может быть еще в логике что-то можно улучшить, надо подумать ;)

@zxqfox Спасибо, в ближайшее время допилю. Не знаю пригодится ли такой блок кому то еще. Может в отдельный репозиторий оформить его?

Пригодится, если будет сделан хорошо. В целом функционала там не много, но много подводных камней, которые требуют проработки. Поэтому, я только за ;-). Когда-нибудь еще появится npm для bem библиотек — и такие микроблоки там будут очень кстати.

upd В общем, пока жду в результата выдачи команды: bower search 'bem-' :fire:

Добавил в bower bem-scrollspy

А bindToWin откуда идёт? Попробовал его повесить в "коробочной" версии - ничего не заработало.

https://github.com/bem/bem-core/blob/v2/common.blocks/i-bem/__dom/i-bem__dom.js#L11 https://github.com/bem/bem-core/blob/v2/common.blocks/i-bem/__dom/i-bem__dom.js#L428

@Guria

в "коробочной" версии

Это как?

@kompolom без подключения разных модулей (блоков в зависимостях)

@Guria, спасибо за наводку :) Понял свою ошибку.