Недостатки всегда использовать live () вместо bind () для уникальных элементов DOM? - PullRequest
3 голосов
/ 20 октября 2010

При написании событий привязки jQuery я обычно использую псевдонимы bind() (click(), submit() и т. Д.).

Но, чем больше я использую динамически генерируемый контент, тем больше я нахожу его неоднозначным относительно того, когда bind() не будет работать, и заканчиваю отладкой в ​​течение получаса, пока я не попробую live(), и это работает,

В параметрах селекторов идентификаторов (например, '#foo', а не .classes или элементов ('input')):

Есть ли недостатки в том, что вместо этого всегда используется live()bind() для этих типов привязок, кроме отсутствия удобных псевдонимов, поскольку может быть только один элемент DOM, связанный с конкретным идентификатором?

===========

РЕДАКТИРОВАТЬ: я не спрашиваю, в чем разница между bind() и live();это было покрыто.Я спрашиваю, каковы недостатки простого использования live () по умолчанию, поскольку соблазн состоит в том, чтобы делать это в тех случаях, когда вы не можете ошибочно отменить выбор (например, когда вы используете #uniqueDomElement), и избегать размышленийо том, когда bind() не подходит.

Ответы [ 3 ]

3 голосов
/ 21 октября 2010

Основным недостатком .live() является вес (это применяется при использовании большого числа обработчиков .live()), поскольку он прикрепляет обработчик событий к document и события по умолчанию всплывают там (вся основа того, как это работает), что означает, что когда событие достигает документа, необходимо проверить несколько вещей:

  • Есть ли у меня какие-либо события .live() для этого типа событий?
  • Если да, совпадает ли элемент, из которого произошло событие, с какими-либо селекторами для этих обработчиков .live()?

Первое довольно дешево, второе нет. Давайте рассмотрим самый распространенный пример - событие click. click событие пузыри, пока все хорошо. Допустим, у нас есть один или несколько .live() обработчиков событий для click, зарегистрированных на document ... теперь мы должны просмотреть все этих обработчиков и сравнить их селекторы для элемента, из которого произошло событие, чем больше у вас обработчиков, тем дороже это становится и происходит с с каждым кликом , что на сегодняшний день является самым большим снижением производительности для .live().

Есть и другие проблемы, такие как присоединение / удаление обработчиков, но это управление вашими обработчиками ... вышеуказанные проблемы производительности, которые применяются, когда у вас есть большое количество обработчиков, являются основной проблемой при сравнении их с прямым .bind() вызов.

0 голосов
/ 21 октября 2010

Это балансирование. Live() привязывает события к документу и ищет цель сработавшего события. Преимущество «жить» (то есть делегирование событий в целом) состоит в том, что вы связываете только один обработчик событий для бесконечного числа аргументов. Bind() присоединяет обработчик событий непосредственно к самому элементу, поэтому, если у вас есть 1000 строк в таблице и вы запускаете $('tr').bind(...), вы будете связывать 1000 обработчиков событий. Если бы вы сделали $('tr').live(...), вы бы просто связали один обработчик событий.

Вы можете встретиться посередине, используя .delegate (), он отличается от живого, потому что вы указываете контекст события. Следовательно, он не всегда срабатывает, поэтому более эффективен. Используя пример таблицы, вы бы использовали $('table').delegate('tr', 'click', function() { .... });. Вы получаете преимущества как bind, так и live с минимальными недостатками: вы связываете 1 обработчик событий, его будущее (с контекстом только этой таблицы), вы не пересекаете весь dom, ища элементы 'tr'.

Связывай, живи и делегируй, все имеют свое место.

Кроме того, отметим, что делегат - это еще один способ сделать $ ('tr', $ ('table') [0]). Live (), но это выглядит ужасно, поэтому делегат существует.

0 голосов
/ 21 октября 2010

Проблема, с которой вы сталкиваетесь с bind, заключается в том, что вы должны выполнить вызов bind после того, как элементы появятся на странице. Обычно люди вызывают bind для готового документа, чтобы они могли прикрепить поведение к элементам на странице. Если после этого элемент добавляется на страницу с помощью javascript, вам потребуется применить тот же самый вызов связывания для новых добавленных элементов, что часто бывает громоздким делом, и поэтому вы можете использовать вместо него .live.

.live использует делегирование событий, что означает, что вместо привязки обработчика функции к определенным элементам на странице jquery управляет всеми различными вызовами в реальном времени, так что когда вы делаете какое-то действие, для которого существует живой обработчик, оно будет проверьте, соответствует ли элемент, над которым вы выполняли это действие, указанному селектору (я думаю, именно так он и работает). Я предполагаю, что он добавляет событие в тело документа (для кликов / действий мыши). Я не уверен в деталях, но я знаю, что иногда вы можете получить странное поведение с live, если вы используете его для всего ... Обычно лучше всего использовать, если у вас есть тонны элементов, к которым вы будете применять какое-то поведение или если вы будет добавлять эти элементы динамически через JavaScript.

Прочтите документы для получения дополнительной информации: http://api.jquery.com/live/

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...