jQuery each — где создавать обработчики

[rash]

Здравствуйте.

 

Вопрос предельно нубский, но попробую не стесняться

 

Задача — после загрузки страницы обойти все элементы по селектору (в частности, с заданным классом) и инициализировать для них некоторое поведение.

 

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

 

Первый — обработчики создаются в замыкании для каждого экземпляра:

$('.class').each(function() {	var self = $(this);	var data = 1;	self.on('event1', 'child1', handler1)	    .on('event2', 'child2', handler2)	    .on('event3', 'child3', handler3);	function handler1() {		...	}	function handler2() {		...	}	function handler3() {		...	}});

Здесь при каждой итерации each в замыкании будет создаваться новый комплект обработчиков, из которых будут доступны данные data и сам элемент self просто из скоупа. Это упрощает доступ к данным, их сохранение и обмен между обработчиками.

 

Второй способ — обработчики создаются внутри внешнего замыкания:

(function() {	$('.class').each(function() {		var self = $(this);		var data = 1;		self.on('event1', 'child1', function() { handler1(self, data); })		    .on('event2', 'child2', function() { handler2(self, data); })		    .on('event3', 'child3', function() { handler3(self, data); });	});	function handler1(self, data) {		...	}	function handler2(self, data) {		...	}	function handler3(self, data) {		...	}}());

Здесь обработчики существуют в единственном экземпляре, но чтобы они могли оперировать общими данными, эти данные необходимо передавать в явном виде. Можно, конечно, привязать их к DOM-элементу, но его, тем не менее, передавать придется.

 

Вот и вопрос — стоит ли экономия на количестве обработчиков усложнения доступа к данным? Какой из вариантов выбрали бы вы?

[wwt]

если подумать то и цикл там не нужен.

что-то типо такого:

$(document).ready(function(){   var data = 'red';   $('.class')     .on('click', '.c_1', data, handler)     .on('click', '.c_2', data, handler)     .on('click', '.c_3', data, handler);});function handler(event) {    var $this = $(this);    var data = event.data;    $this.css('background-color', data);}

Обработчиков можно сделать 3 или больше, но можно и передавать часть функционала через объект data, он попадает в event.data , и ссылку на контекст тоже передавать не нужно.

 

На фидле запилил http://jsfiddle.net/H8hBp/

 

UPD забыл если нужен родитель .class то ведь опять же есть  parent()

Edited February 13, 2014 by wwt

[rash]

Цикл не нужен, просто так получается удобнее, и опять же за счет замыкания на общего родителя, которому делегирую обработчики, проще сохранять данные для каждого экземпляра отдельно (а это и нужно).

 

В вашем случае data получается общей для всех экземпляров.

 

Конечно, данные можно привязать к DOM-элементу через .data, но мне не хочется этого делать уже только потому, что этого можно не делать, воспользовавшись обычной переменной. Или у сохранения в DOM есть какие-то преимущества, которые я упускаю? Пока мне кажется, что это имеет смысл делать, если к данным должен быть доступ из разных блоков или частей документа, которые не смогут воспользоваться общей переменной.

 

Впрочем, ваш подход можно попробовать адаптировать к моему второму варианту. Что-то я упустил из виду, что при назначении обработчика можно данные передавать через event.data. Код немного увеличится, но по памяти должно получиться экономичнее все равно.

 

Свежий взгляд помогает

[wwt]

Если данных много то можно воспользоваться Local storage это ещё удобнее чем переменные, данные запоминаются на клиенте и доступ с любой страницы сайта будет. Или уж если переменная то как вариант использовать один глобальный объект для данных и обращаться к нему из любого места скрипта. Мне кажется так лучше чем кучу кода созданного для того же самого.

[rash]

Штука в том, что данных немного, но они должны быть назависимыми для каждого экземпляра. Local storage ни к чему, они нужны только на время существования страницы и только на этой странице.

 

В общих чертах — «поведение» каждого блока требует хранения его состояния. И глобальный объект тоже ни к чему — они имеют смысл только внутри самого блока, к ним не нужен доступ извне. Но каждый блок должен вести себя независимо, то есть хранить свое собственное состояние отдельно от других.

[wwt]

Штука в том, что данных немного, но они должны быть назависимыми для каждого экземпляра. Local storage ни к чему, они нужны только на время существования страницы и только на этой странице.

 

В общих чертах — «поведение» каждого блока требует хранения его состояния. И глобальный объект тоже ни к чему — они имеют смысл только внутри самого блока, к ним не нужен доступ извне. Но каждый блок должен вести себя независимо, то есть хранить свое собственное состояние отдельно от других.

тогда data не плохой вариант. И получить доступ к данным можно из любого места скрипта. Чем городить огород с переменными и их передачей в обработчик.

[rash]

Ну вот и я пришел к такому же выводу, просто, вероятно, когда-то бегло читал документацию по .on, и на data не обратил внимания, так и жил в уверенности, что такой возможности нет

[nerv]

rash, любопытства ради - задача какая?

[rash]

Задача — что-то типа кастомных контролов. Соответственно, на странице их может встретиться довольно много (заранее неизвестно), и каждый должен вести себя самостоятельно. Все данные, которые от него могут понадобиться другим частям скрипта будут доступны из DOM-представления (все равно все делается на базе стандартных контролов, просто вокруг них навешивается дополнительная функциональность и логика), остаются те же value, onchange, onblur и добавляются некоторые jquery-события.

 

Совсем по-хорошему, наверное, надо плагин написать для этого. Но сейчас не планирую.