Велосипеды на Javascript и jQuery

Автор, пиши еще :)

Сам вот начинал прям как у вас всё расписано! Новичкам must read!

динамическое навешивание обработчиков появилось изрядно раньше в v1.3, через метод «.live», впоследствии замененный на чуть более удобный «.on».

Полезная заметка)

Обычно статьи про jquery здесь удручают, но не эта) Надеюсь, продолжение следует.

Очень как-то за уши притянуто. Соглашусь, всегда лучше использовать изящные решения. Но велосипедами такие моменты не назвать. Можно использовать библиотеку по-разному, и в первую очередь используются самые простые варианты, которые позволяют быстро решить задачу, а уже потом рефакторинг.
А говорить что $post плох тем, что у него есть последним параметром можно передать dataType это как-то уж совсем перебор. Можно посоветовать описывать обработчики в отдельном месте со всеми простынями кода. Тогда это не будет такой проблемой, например.

По поводу post, я не согласен. Во первых все функции возвращают deffered object, у которых есть есть методы done,complete,fail(а error является устаревшим). Тип преходящих данных нужно указывать на стороне сервера отправляя правильный заголовок content-type:application/json jQuery cам поймет, как с ним работать(читаем документацию:The type of data that you're expecting back from the server. If none is specified, jQuery will try to infer it based on the MIME type of the response (an XML MIME type will yield XML, in 1.4 JSON will yield a JavaScript object, in 1.4 script will execute the script, and anything else will be returned as a string). ). Поэтому писать обработчик в sucess, не очень хорошо.

Не совсем понял про $.post и $.ajax

С остальным согласен. Особенно про Неймспейсы и data-*

Небольшое дополнение, если на проекте вы используете jQuery UI. То в нем уже зашиты многие константы кодов клавиш в объекте $.ui.keyCode. Тут не стоит забывать, что если пишете какой-то плагин и соберитесь выкладывать в сообщество, нужно подумать, следует использовать или определить свои константы.

Правильное слово тут «Антипаттерн» вместо «Велосипед», если я не ошибаюсь. Велосипедов в статье, собственно, ровно один – это обращение к замусоренным атрибутам – и тот крохотный.
Из антипаттернов часто ещё можно встретить бесконечное дёргание одного и того же хендлера или как его назвать.

$( '#one_long_selector' ).someAction();
...
$( '#one_long_selector' ).getSomeAttribute();
...
$( '#one_long_selector' ).writeSomeValue( value );

Правильное, на мой взгляд:

var _handler = $( '#one_long_selector' );
_handler.someAction();
...
_handler.getSomeAttribute();
...
_handler.writeSomeValue( value );

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

я начинающий jquery-ст, и есть вопрос по теме:
есть $('...').click() и $('...').on('click', function() для в том числе создающихся элементов на странице.
Можно ли использовать второй вариант вместо первого и есть ли подводные еще, кроме падения производительности, описанной в статье?

Биндер событий «on» хороший, но отнюдь не факт, что он всегда эффективнее по производтельности.

В вашем случае — да, он не слушает события на 1000 комментариев. но на каждый чертов клик на странице — обрабатывает кликнутый элемент и всех его родителей (баблинг события) и ищет, «а не совпадает ли он с каким-нибудь из навешанных селекторов».

Вешать on на body можно только в RIA, и то не всегда. В остальных случаях — его контейнер нужно максимально «углублять» (т.е. брать на столько глубокий элемент, на сколько можно)

Про Namespaced events:
на event можно навешивать функцию (не анонимную) и тогда её можно будет затем анбиндить явно.

Для клавиатурных содытий есть новый стандарт DOM Events Level 3, который определяет свойства key и char.

document.addEventListener('keyup', function(e) {
  if(e.key == 'Esc' || e.key == 'Enter') { }
})

Попробовать на вкус можно тут.

А константы Event.DOM_VK_* есть в некоторых браузерах (сейчас нету возможности посмотреть, но, по-моему, в FF есть) и были определены предыдущей редакцией стандарта и уже успели устареть

Есть же $.getJSON.

а если в какой то момент нам захотелось изменить метод с GET на POST?

Спасибище огромное! Постоянно наступаю на все грабли какие есть в JS. Буду благодарна еще материалам по этой же тематике.

Мои 5 копеек.

2. Бытует мнение что лучше вместо selector.data использовать $.data
jsperf.com/jquery-data-vs-jqueryselection-data

Есть небольшой неочевидный косяк с этим способом, нужно передавать DOM элемента, а не объект jQuery, поэтому ваш пример можно переписать так:

var id = $.data(this, 'id');

Я предполагаю что this возвращает DOM элемент, но если вдруг у вас собственный селектор, то, вероятнее всего нужно будет получить из него DOM элемент, вот так, например:

$('.my_class')[0]

4. Маленькая неточность, лучше не использовать «тяжелые» селекторы
24ways.org/2011/your-jquery-now-with-less-suck

Ваш пример лучше записать так:

$('body').find('a').on('click', '.external', function(e) {
    //функция будет вызвана при клике на любую ссылку с классом external
});

Приятно читать то, о чём хоть немного знаешь, но взгляд уже «зашоренный». Ждём продолжения.

Стоит еще момент уточнить насчет:

$('body').on('mousemove', selector, function() {
//
});

А то щас все новички будут пользовать только его и будут считать что это правильно.
Есть два способа повесить обработчик на «selector»

Первый:

$('body').on('mousemove', selector, function() {
//
});

Второй:

$(selector).on('mousemove', function() {
//
});

Разница между ними заключается в том, что в первом варианте событие вешается на самом деле на «body», и когда оно срабатывает то жквери прибегает по всем детям body (body это, кстати, не догма, может быть любой другой элемент родителем которого является наш selector) и вызывает наш обработчик для элементов которые соответствую selector и который попали под нужное событие, именно по этому этот обработчик срабатывает даже для новых элементов.
Второй же вариант вешает событие непосредственно на сами элементы.
Соответственно у обоих методов есть плюсы и минусы, которые достаточно очевидны.

тогда получить идентификатор будет очень просто:

var id = $(this).attr('data-id')

Один косяк — ссылку на элемент по этому data-id будет получить дорого, так как селекторы по id работают намного быстрее

Кто-нибудь исследовал поддержку браузерами произвольных атрибутов data-*?

В пункте 4
Решение: в jQuery 1.7 есть метод on, который привязывает обработчики события, фильтруя элементы по селектору.

В пункте 5
Несмотря на то, что namespaced events были добавлены в jQuery 1.2 — ими мало кто пользуется (Мне кажется большинство людей просто не знают о них).

И в этом же пункте используете метод on, который появится только в 1.7

В качестве альтернативы «Namespaced events» можно выносить функции обратного вызова в переменные и биндить их уже этими переменными. Тогда они также легко снимаются.

Пример прямо из мана api.jquery.com/unbind/

var handler = function() {
alert('The quick brown fox jumps over the lazy dog.');
};
$('#foo').bind('click', handler);
$('#foo').unbind('click', handler);