Должны ли все события включения/выключения базовой линии быть заменены на listenTo/stopListening?

Насколько я мог сказать, listenTo и stopListening должны заменить on и off соответственно. Правильно ли я это понимаю? Существует ли ситуация, когда on/off следует использовать вместо listenTo/stopListening?

Edit:

Когда я перешел к рефакторингу своего кода, стало очевидно, что для on для listenTo есть некоторые случаи. Документация довольно понятна, потому что когда один объект прослушивает другой объект:

Расскажите объекту, чтобы прослушать конкретное событие на другом объекте.

Поэтому, когда a collection или model прослушивает событие сам по себе, мы должны использовать on вместо listenTo.

Предполагая, что у меня это правильно...

Следующее простое правило:

Используйте listenTo при прослушивании событий на другом объекте. Используйте on при прослушивании событий на себе.

ОТВЕТЫ

Ответ 1

По большей части вы понимаете это правильно. Вот обсуждение этого вопроса из своего репозитория github: https://github.com/documentcloud/backbone/issues/1923#issuecomment-11462852

listenTo и stopListening отслеживать состояние. Он позаботится об очистке для вас ценой небольшого накладного расхода кода. В почти каждом случае я могу думать о том, что вы хотите, чтобы это поведение было для ваших взглядов, но вы не ошибетесь и для обработки входящих и исходящих вызовов сами; они не будут обесценивать on и off в ближайшее время.

Ответ 2

Копирование выписки из интересного сообщения в блоге, которое я прочитал недавно. Надеюсь, что это поможет.

Избегайте общих ловушек: создание утечек памяти, не отменяющих события

Общий шаблон в Backbone.js создает представления, которые прослушивают изменения в моделях или коллекциях. Этот метод обычно предназначен для того, чтобы позволить автоматически повторно отображать представление при изменении базовых данных. Это также означает, что для больших коллекций мы можем получить множество представлений (по крайней мере один для каждой модели в коллекции), которые мы можем динамически создавать или уничтожать на основе изменений данных.

Проблема возникает, когда мы удаляем представление (обычно, вызывая его метод .remove()), но забывая отменить методы, которые прослушивают изменения модели. В этом случае, даже если наш код больше не может содержать ссылку на это представление, он никогда не собирает мусор, так как модель все еще содержит такую ​​ссылку через обработчик событий.

Возьмите это представление, например:

var SomeModelView = Backbone.View.extend({
   initialize: function() {
     this.model.on('change', this.render, this);
   },
   render: function() {
     // render a template
   }
});

При вызове метода .remove() обработчик событий "change" (наша функция визуализации) по-прежнему привязан. Таким образом, хотя элемент DOM может быть удален, сам объект представления никогда не освобождается из памяти.

Решение этого легко (особенно с Backbone 0.9.x) - все, что нам нужно сделать, это прекратить использование .on() при привязке обработчика события. вместо этого мы можем использовать новый метод .listenTo(), например:

initialize: function() {
    this.listenTo(this.model, 'change', this.render);
}

Самой большой разницей здесь является смещение ответственности от модели к точке зрения. Это означает, что всякий раз, когда мы вызываем .remove(), представление автоматически отвязывает любое событие, связанное с ним с помощью метода .listenTo(), по существу фиксируя эту общую утечку.