Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 126
Плюсанул бы, да не могу.
Однозначно в избранное =)
Однозначно в избранное =)
Хорошая статья :)
Пора открывать церковь jQuery.
We need moar.
Если серьёзно, то столько всего оказывается можно сделать лучше и удобнее…
Если серьёзно, то столько всего оказывается можно сделать лучше и удобнее…
Спасибо.
Это хорошая идея публиковать статьи в стиле так называемых «best practice».
Это хорошая идея публиковать статьи в стиле так называемых «best practice».
Дополнение удалось на славу, спасибо. На самом деле, jQuery от версии к версии становится все более удобным и интересным, но часто разработчики по привычке не используют «новшества».
Хм, а зачем parentsUntil, если можно просто .parents? Сразу указываем целевой селектор и вот он у нас.
Часто бывает, что мы находимся в глубине табличной верстки. И нужно добраться до ближайшей строки. Тогда получится что-то типа
$(this).parents("tr"), хотя лучше, наверное, $(this).parents("tr:first"), потому что могут быть вложенные таблицы. Вариант с .closest() выглядит так же, как и проговаривается.Так-то да, имею в виду, что совсем большой конструкцией пользоваться в принципе не обязательно, а так разница очень невелика (по крайней мере на практике — мне редко доводилось рыться в сильно вложенной табличной верстке)
После этой статьи перечитал что есть parents и closest и везде в проекте запенил parents -> closest. На сколько я понял последний метод менее ресурсоемкий:
The .parents() and .closest() methods are similar in that they both traverse up the DOM tree. The differences between the two, though subtle, are significant:
.closest()
-Begins with the current element
-Travels up the DOM tree until it finds a match for the supplied selector
-The returned jQuery object contains zero or one element
.parents()
-Begins with the parent element
-Travels up the DOM tree to the document's root element, adding each ancestor element to a temporary collection; it then filters that collection based on a selector if one is supplied
-The returned jQuery object contains zero, one, or multiple elements
The .parents() and .closest() methods are similar in that they both traverse up the DOM tree. The differences between the two, though subtle, are significant:
.closest()
-Begins with the current element
-Travels up the DOM tree until it finds a match for the supplied selector
-The returned jQuery object contains zero or one element
.parents()
-Begins with the parent element
-Travels up the DOM tree to the document's root element, adding each ancestor element to a temporary collection; it then filters that collection based on a selector if one is supplied
-The returned jQuery object contains zero, one, or multiple elements
Мне кажется, что людей, которые пишут
очень сложно встретить. Они живут только в вольерах нет.
$(".info").html("").html("<b>Ok</b>")
А вот и есть.
Видимо они из своих вольеров делали один проект, которому мне пришлось переписывать всю клиентскую часть.
Видимо они из своих вольеров делали один проект, которому мне пришлось переписывать всю клиентскую часть.
Разделяю вашу горечь и жду интересных постов на govnokod.ru
— Видишь суслика?
— Нет.
— А он есть…
— Нет.
— А он есть…
Круто! Спасибо! Не могу плюсануть, к сожалению :(
С точки зрения производительности разницы особой нет. Делал замеры в мозиле — различия заметны только при 10000 итераций. Второй вариант дороже на 20-30 милисекунд.
До 100 итераций оба варианты одинаковы до милисекунды. Хотя, мне больше нравится второй вариант.
for (i = 0; i < 100; ++i) {
if ($("input").prop("checked")) {}
if ($("input").is(":checked")) {}
}
До 100 итераций оба варианты одинаковы до милисекунды. Хотя, мне больше нравится второй вариант.
Многие задавались этим вопросом :) Советую взглянуть: jsperf.com/prop-vs-ischecked/5
Потому что это хардкор, javascript-хардкор, это настоящий код из Мытищ!!!
А на самом деле, легко понять, что при использовании checked мы просто получаем ссылку на DOM-элемент и запрашиваем его свойство, а во всех остальных случаях вызываем функции jQuery. Сам вызов функции уже «стоит» достаточно, а сколько проверок они таят внутри — я не смотрел и не знаю.
А на самом деле, легко понять, что при использовании checked мы просто получаем ссылку на DOM-элемент и запрашиваем его свойство, а во всех остальных случаях вызываем функции jQuery. Сам вызов функции уже «стоит» достаточно, а сколько проверок они таят внутри — я не смотрел и не знаю.
Потому что никому не нужно проверять состояние чекбокса 1000 раз в секунду?
jQuery кеширует запросы к DOM и вероятнее всего вы получаете данные именно из него, а не поиск в каждой итерации.
if (elem.checked)
Безусловно, полезная статья.
Однако мне кажется, что все эти ситуации возникают от того, что люди не читали документацию jQuery. Всего этого можно избежать с минимальным наличием мысли и знанием документации, которая очень даже хороша.
Однако мне кажется, что все эти ситуации возникают от того, что люди не читали документацию jQuery. Всего этого можно избежать с минимальным наличием мысли и знанием документации, которая очень даже хороша.
Статья полезная.
Понравился подход «сначала проговори — потом пиши».
Понравился подход «сначала проговори — потом пиши».
Отличная статья! В ней как раз указаны некоторые пункты (например, про closest), которые я не стал описывать в habrahabr.ru/post/149237/ (чтобы статья не была слишком длинной)
В дополнение к первому пункту мне еще встречался следующий велосипед:
вместо лаконичного
$('.nav').removeClass('first').removeClass('second').removeClass('third');
вместо лаконичного
$('.nav').removeClass('first second third');
Я бы еще добавил, что не стоит забывать о такой замечательной вещи, как Deferred Object при работе с ajax и анимациями.
А статья отличная :)
А статья отличная :)
Опишите подробности. Я конечно поищу, но было бы удобно понять суть в комментариях.
Для себя я отметил, что крайне удобно с их помощью обрабатывать все виды асинхронных операций.
Вот тут товарищ довольно хорошо объясняет, в чем соль.
Вот тут товарищ довольно хорошо объясняет, в чем соль.
Если я правильно понимаю принцип работы ajaxSetup, то указанный пример ломает параметры для всего кода, который может идти после нашего и не знать, что мы меняли параметры. Нужно как-нибудь восстанавливать стандартные.
Настройки по умолчанию, т.е. стандартные настройки, заданные с помощью
Только одно замечание:
.ajaxSetup, не затираются одноименными настройками индивидуального AJAX-запроса. Но их можно изменить вызовом еще одного .ajaxSetup.Только одно замечание:
$.ajaxSetup({data: { new_prop: new_val }}) не сотрет предыдущие параметры data, а только обновит (или создаст) указанные. Во всяком случае, в последней версии jQuery.
Особо спасибо за 4 пункт, очень полезно.
Не останавливайтесь, пожалуйста.
Не останавливайтесь, пожалуйста.
Код типа
$(".info").html("")
Собственно, в статье как раз затронут вопрос утечки. Хотя, действительно, я не акцентировал внимание на том, что
Но в вашем примере —
.empty() предпочтительнее как раз тем, что занимается smart-очисткой элемента.Но в вашем примере —
.html("") — не будет утечек! Потому как jQuery вызовет .empty() перед вставкой нового значения (в данном случае у вас пустая строка).
Я люблю jquery, но ее взаимность порой огрошивает, когда после серии hide/show вместо изначального display:inline-block я получаю display:block.
использую для этого классы — в одном display: none, в другом display: inline-block и меняю их.
Это нарушение основ верстки. HTML код не должен содержать данных о визуальном отображении контента. В идеальном мире.
C каких это пор применение классов для html элементов стало нарушением основ?
Класс html не должен нести информации об отображении элемента. Это теоретически позволяет менять внешний вид сверстанной страницы, не трогая html-код. На практике, разумеется, встречаются всякие плавающие элементы, для которых важно, какой идет за каким прочая, прочая…
Но все-таки вы должны видеть разницу между
и
К тому же, конкретно в вашем примере нарушается еще один акт модульности — разделение отображения (CSS) и логики (JS).
Но все-таки вы должны видеть разницу между
<div class="important-info-block"></div>
и
<div class="left inline-block black-border medium-border-radius"></div>
К тому же, конкретно в вашем примере нарушается еще один акт модульности — разделение отображения (CSS) и логики (JS).
У метода show() есть особенность, из-за которой он считается не очень быстрым. Дело в том, что этот метод, перед тем как сделать элемент видимым пытается узнать значение его свойства display, чтобы проставить его правильно. И при проявлении большого количества элементов за раз, show() может вызвать приличные тормоза. Так что для оптимизации производительности в огромных программах лучше все же использовать css(«display»,«block»).
Интересно, никогда об этом не задумывался. jsperf.com/showhide-vs-css/4
Но не всегда удобно бывает хардкодить стили. С IE и скрытием строк таблиц у меня были определенные проблемы.
Но не всегда удобно бывает хардкодить стили. С IE и скрытием строк таблиц у меня были определенные проблемы.
Хороший стиль изложения, да и по-делу говорите. Продолжайте, пожалуйста!
«jQuery любит вас»
Спасибо, день начался с улыбки ;) Буду теперь весь день это проговаривать
Спасибо, день начался с улыбки ;) Буду теперь весь день это проговаривать
$("#history, #description, #category, #contact").hide()
Мне кажется, это скорее вредный совет в свете наличия все еще ощутимого количества IE младше 9-ой версии. Если я правильно помню, Sizzle при отсутствии querySelectorAll выполняет этот селектор через getElementsByTagName('*') и последующую фильтрацию результата в javascript'е, что трагически сказывается на производительности.
Это справедливо только для элементов к которым обращаются не по id.
Признаю, был неправ, Sizzle оказался лучше, чем я думал http://jsfiddle.net/6mFJP/1/
Раз вы пишите такие статьи, то вам неплохо было бы ознакомиться вот с этим это по поводу второго пункта.
Спасибо. Почитал по вашей ссылке. Насколько я понял, человеку не понравилось, что
.hover() выглядит для него как событие, а в обработчике подсовывается тип mouseenter или mouseleave, и что нельзя вызвать событие вручную. Но в документации ясно написано, что .hover() является сокращением для последовательного навешивания указанных обработчиков. Поправьте меня, если я не прав — самому интересно, потому как у тикета стоит статус — closed enhancement: fixed, при этом человек сослался на документацию, в которой, мол, не рекомендуется использование ховера, но на данный момент там об этом ничего не сказано.Кстати, лично я всегда использую on для прикрепления событий, чтобы явно показать, что я прикрепляю событие, а не делаю trigger события. Позволяет избежать неочевидных проблем и улучшает читабельность.
Пример, который приведет непонятно к чему:
Тем более, что не так много экономят shorthand функции
Пример, который приведет непонятно к чему:
var fn = function(){}
...
//где то в другом месте fn = undefined;
...
$('.spend_the_money').click(fn);
Тем более, что не так много экономят shorthand функции
element.on('click', handler)
element.click(handler)
Вы видать не дочитали или сделали это невнимательно, я вот про это «The docs already call this name „strongly discouraged for new code“, I'd like to deprecate it officially for 1.8 and eventually remove it.»
Видимо, плохо сформулировал мысль, но я выше как раз написал, что человек говорит то, что не подтверждается фактом. «The docs already call this name «strongly discouraged for new code»», но я не нашел об этом упоминания в доках. Может, я не там смотрю? :)
Вот вам факты blog.jquery.com/2012/08/09/jquery-1-8-released/ #11731: Deprecate «hover» pseudo-event
Как я мог пропустить ".closest()" во время изучения документации jQuery? LionMuzzle, спасибо, довольно часто мне его не хватало во время работы с DOM.
От себя хочу добавить небольшой protip для jQuery.
Порой нужно добавить элементы в текущую разметку, скажем после ajax запроса, и обычно это делают через:
Но когда таких элементов много, или очень много (представьте подгрузку нескольких тысяч клиентов в список) — это сказывается на производительности. Все дело в селекторе, который создает <option>. К сожалению сейчас не могу привести результаты бенчмарков, но есть очень простое решение проблемы:
От себя хочу добавить небольшой protip для jQuery.
Порой нужно добавить элементы в текущую разметку, скажем после ajax запроса, и обычно это делают через:
$('<option />').prop('value', response[k].value).text(response[k].title).appendTo(parentElement);
Но когда таких элементов много, или очень много (представьте подгрузку нескольких тысяч клиентов в список) — это сказывается на производительности. Все дело в селекторе, который создает <option>. К сожалению сейчас не могу привести результаты бенчмарков, но есть очень простое решение проблемы:
// Перед итерацией
var optCreateSel = document.createElement('option'); // Создаем "selector" для jQuery
// Непосредственно в самой итерации
$(optCreateSel).prop('value', response[k].value).text(response[k].title).appendTo(parentElement);
Поидее, так даже быстрее — jquery объект только один раз создается.
// Перед итерацией
var optCreateSel = $("<option />"); // Создаем "selector" для jQuery
// Непосредственно в самой итерации
optCreateSel.prop('value', response[k].value).text(response[k].title).appendTo(parentElement);
И еще быстрее:
// Перед итерацией
var optCreateSel = $(document.createElement('option')); // Создаем "selector" для jQuery
// Непосредственно в самой итерации
optCreateSel.prop('value', response[k].value).text(response[k].title).appendTo(parentElement);
Вообщем не сработает. Ни мой ни ваш пример. Надо добавлять clone()
learn.javascript.ru/play/W4BiPb
можно по отдельности посчитать
learn.javascript.ru/play/W4BiPb
можно по отдельности посчитать
Какой чудный protip. Мало того, что неправильно работает, так еще в 5 раз медленнее обычной склейки всех value в строку.
Небольшое дополнение к первому пункту. Если нужно показать/спрятать что-то по условию, то вместо
более короткая запись:
if (someValue)
$j(selector).show;
else
$j(selector).hide();
более короткая запись:
$j(selector).toggle(someValue);
Не согласен с половиной написанного:
1.
2.
3.
1.
$(".info").html("") знают все, а за empty — часть людей полезет в доки. «Особые случаи не настолько особые, чтобы нарушать правила.» (с) zen.py2.
$("#history, #description, #category, #contact").hide() — удобнее отлаживать код (комментировать отдельные hide) когда они идут списком.3.
$.ajaxSetup — вообще непонятно какая либа его переопределит, чтобы на него полагаться. Проще написать обычную js функцию делающую запрос с нужными дефолтными параметрами.
var person = $(".name").closest(".person ")Из кода следует, что некая сущность
person взывает к своему предку person:<div class="person">
<div class="name">Name</div>
</div>Поправьте меня, но почему код не исполняется в контексте person?
var methods = {
_getName: function() {
$(this).find('.name');
// Do smth.
}
}
$.fn.my_plugin = function() {
// Init, etc.
}
$('.person').my_plugin();Помоему это в 90 % случаев признак спагетти-кода.
$(«вас»).love();
Стиль изложения хороший, статья продумана.
Но меня почему-то пугает такое количество плюсов к статье.
Но меня почему-то пугает такое количество плюсов к статье.
По-моему не упомянули:
вместо:
$('.element', '.container')
вместо:
$('.container').find('.element')
Второй вариант более читабельный.
А что насчет производительности?
С производительностью всё будет хорошо habrahabr.ru/post/149237/#comment_5046360
Может, конечно не в тему, но все же. Интернет у меня нестабильный и пользоваться документацией через браузер плохой вариант. На официальном сайте jQuery я нашел доки в формате chm, но они только для 1.4. Отсюда вопрос: сильно ли изменился jQuery с этой версии и можно ли ими пользоваться? Есть ли где ни будь доки для 1.7?
Да, есть: jqapi.com/
думаю, можно скачать всю документацию чем-то вроде wget-а.
Вместо $.ajax часто можно использовать более короткую запись: $.get или $.post
Я бы назвал этот пост «jQuery любит вас» :))
Не знал про ajaxSetup, спасибо!
>Обратите внимание, что параметры data из $.ajaxSetup и $.ajax склеиваются, и серверу посылается их сумма (параметры из $.ajax перезатирают одноименные из $.ajaxSetup).
Все-таки, не перезатирают, а склеиваются.
Не знал про ajaxSetup, спасибо!
>Обратите внимание, что параметры data из $.ajaxSetup и $.ajax склеиваются, и серверу посылается их сумма (параметры из $.ajax перезатирают одноименные из $.ajaxSetup).
Все-таки, не перезатирают, а склеиваются.
Надо будет, что то аналогичное подобрать но для других библиотек.
Для своих проектов я использую MochiKit, а по работе Dojo.
Для своих проектов я использую MochiKit, а по работе Dojo.
Насчет .html и .empty
github.com/jquery/jquery/blob/master/src/manipulation.js#L191
Посмотрите как работает .empty, .html отработает в разы быстрей.
github.com/jquery/jquery/blob/master/src/manipulation.js#L191
Посмотрите как работает .empty, .html отработает в разы быстрей.
Может, вы имели ввиду обратное?
Вообще, в малых дозах разницы нет, какой способ использовать. Но статья призывает писать более понятным языком, говорящим, что вы делаете, а не как, если это уместно и разумно.
.html никак не может быть быстрее, так как внутри него вызывается .empty. Опять же: тест1, тест2, тест3.Вообще, в малых дозах разницы нет, какой способ использовать. Но статья призывает писать более понятным языком, говорящим, что вы делаете, а не как, если это уместно и разумно.
Смотрите исходники внимательней.
github.com/jquery/jquery/blob/master/src/manipulation.js#L249
github.com/jquery/jquery/blob/master/src/manipulation.js#L249
empty используется в html только при вызове исключений, а это не происходит на обычных элементах.
А по тестам да, empty быстрей, но это опять же, из-за очистки элементов поодному из ноды =) Я не заметил сразу что оба метода очищаются одинаково.
Если бы не эта строка было бы все наоборот :( Не знаю зачем они так делают, может избавляются от возможных утечек, но это явно лишняя работа очищать то что на следующей строке очистится само.
github.com/jquery/jquery/blob/master/src/manipulation.js#L249
github.com/jquery/jquery/blob/master/src/manipulation.js#L249
empty используется в html только при вызове исключений, а это не происходит на обычных элементах.
А по тестам да, empty быстрей, но это опять же, из-за очистки элементов поодному из ноды =) Я не заметил сразу что оба метода очищаются одинаково.
Если бы не эта строка было бы все наоборот :( Не знаю зачем они так делают, может избавляются от возможных утечек, но это явно лишняя работа очищать то что на следующей строке очистится само.
В 1.7 лучше использовать .on() вместо .bind()
Плохо когда статьи пишут те, кто не очень разбирается.
hover() уже заслуженно deprecated.
В пункте 6 window используется как глобальный склад идентификаторов событий. Когда смотришь на такой код — непонятно кто эти события вызывает. Для подобных вещей в 1.7 добавили $.Callbacks(). И уже пора писать не .bind(), а .on()
hover() уже заслуженно deprecated.
В пункте 6 window используется как глобальный склад идентификаторов событий. Когда смотришь на такой код — непонятно кто эти события вызывает. Для подобных вещей в 1.7 добавили $.Callbacks(). И уже пора писать не .bind(), а .on()
На сколько я понял у trigger и $.Callbacks немного разный функционал.
У первого больше возможностей:
1. можнов ешать на любые элементы
2. можно группировать по евентам
Второе же — утпо свалка калбаков на один евент. Или я что-то не так понял?
Можете повторить мой код с помощю $.Callbacks?
$(document).bind('app.start', function(){
alert('started!)
})
$(document).bind('app.finish', function(){
alert('finished!)
})
$(document).bind('app.action.run', function(){
alert('start action...!)
})
$( function(){
$(document).trigger('app.start);
$('#actionButton').bind('click', function(){ $(document).trigger('app.action.run'); })
$(document).bind('unload', function(){ $(document).trigger('app.finish'); })
})
Только не нужно исправлять ошибки, говорить что я дублирую евенты, считайте это псевдокодом.
У первого больше возможностей:
1. можнов ешать на любые элементы
2. можно группировать по евентам
Второе же — утпо свалка калбаков на один евент. Или я что-то не так понял?
Можете повторить мой код с помощю $.Callbacks?
$(document).bind('app.start', function(){
alert('started!)
})
$(document).bind('app.finish', function(){
alert('finished!)
})
$(document).bind('app.action.run', function(){
alert('start action...!)
})
$( function(){
$(document).trigger('app.start);
$('#actionButton').bind('click', function(){ $(document).trigger('app.action.run'); })
$(document).bind('unload', function(){ $(document).trigger('app.finish'); })
})
Только не нужно исправлять ошибки, говорить что я дублирую евенты, считайте это псевдокодом.
Да, конечно же нужно учить людей писать правильный код. Насколько правильно будет заменить сейчас в статье
.bind() на .on()? Еще хочу контекст window заменить на что-то типа $("#seach-form"). var App = { /* magic */ };
App.on('start', function() { alert('start') })
.on('stop', function() { alert('stop') })
.on('run', function() { alert('run') });
// По хорошему, все что ниже входит в обязанности App
$(function() {
App.start();
$('#actionButton').on('click', $.proxy(App, 'run'));
});
$(window).on('beforeunload', $.proxy(App, 'stop'));
Логичнее, не? Функция App.on реализуется на базе Callbacks. Точно так же на базе Callbacks реализованы события в jQuery, но чистый Callbacks более гибкий.
В принципе, события jQuery работают с произвольными объектами, но это не задокументировано, так что лучше не злоупотреблять:
$(Math).click(function() { alert(this.PI) });
// ...
$(Math).click();
Вы изобралили частный случай, причем совершенно не использовали $.Callbacks =) Триггер событий работает по другому чем $.Callbacks. Если мне нужно много разных событий (отдельно на приложение, отдельно на работу самостоятельных модулей, отдельно на работу просто незначительных действий, то кучу эеземпляров $.Callbacks придется держать по экземпляру на каждый евент, а это уже очень плохая реализация. Евенты же жквери сам держит у себя и избавляет меня от лишней работы. $.Callbacks подходит для закрытых частей которые работают сами по себе.
Я сделал то, что меня попросили, и по-моему читаться оно стало лучше. $.Callbacks() используется внутри функции App.on(), я просто не стал разжевывать. Без сахара можно так:
> Если мне нужно много разных событий… придется держать по экземпляру на каждый евент, а это уже очень плохая реализация.
Не понимаю, чем она плоха. Сейчас сотрудники столкнулись с проблемой: есть у нас такое подобие $(document).bind('app.finish'), только без притянутого за уши document. Вызывается оно PubSub.subscribe('app.finish', callback). В один прекрасный день объектов app стало несколько, и все они бродкастят app.finish. А если обработчик надо навесить на какой-то один? Приходится идти на извраты.
$.Callbacks позволяют все изначально сделать правильно, а не складывать все в одну глобальную помойку. В любом UI фреймворке обработчики вешаются на конкретные экземпляры объектов, а не на глобальный диспатчер, как получается в варианте с $(document).bind()
App = {onStart: $.Callbacks};
App.onStart.add(function() { alert('start') });
> Если мне нужно много разных событий… придется держать по экземпляру на каждый евент, а это уже очень плохая реализация.
Не понимаю, чем она плоха. Сейчас сотрудники столкнулись с проблемой: есть у нас такое подобие $(document).bind('app.finish'), только без притянутого за уши document. Вызывается оно PubSub.subscribe('app.finish', callback). В один прекрасный день объектов app стало несколько, и все они бродкастят app.finish. А если обработчик надо навесить на какой-то один? Приходится идти на извраты.
$.Callbacks позволяют все изначально сделать правильно, а не складывать все в одну глобальную помойку. В любом UI фреймворке обработчики вешаются на конкретные экземпляры объектов, а не на глобальный диспатчер, как получается в варианте с $(document).bind()
Она плоха реализацией, повторите этот пример, и поймете jsfiddle.net/5mPCR/, это ваш эскиз элегантен, когда дело дойдет до реализации все будет выглядеть более убого, а вот мой вариант перенял вашу элегантность + избавил от проблемы с которой столкнулись ваши коллеги =) Сделайте просто для интереса тоже что и я, но своим способом, только не теоретическую постановку а реально работающий кусочек, сравним элегантность и гибкость. Вот тогда можно будет понять что лучше а что хуже, на словах все по другому, вы ведь не работали с $.Callbacks правильно?:) лишь читали документацию по нему.
jsfiddle.net/MeX9P/
В вашем примере используется недокументированная фича, я бы такое не стал делать в проекте, который планируется поддерживать.
В вашем примере используется недокументированная фича, я бы такое не стал делать в проекте, который планируется поддерживать.
У меня всего два замечания:
1. Ваш app нихрена не выполняет своего кода, в отличии от моего, мой сперва выполняет некие дейсвия, затем информирует об этом всех подписавшихся, у вас же тупо болванка которая ниче не делает но только всех информирует о сделанном, это недоработка, мне бы нормальный код, рабочий.
2. jsfiddle.net/MeX9P/1/ По вашему это нормальный класс виджета? У меня будут лишь методы. Обычный класс, простой и понятный.
ЗЫ: Вместо «недокументированной фичи» я могу использовать имена и неймспейсы, евенты будут вида:
$(element).trigger('app.start.namespace');
namespase — имя app (new App('namespace') );
1. Ваш app нихрена не выполняет своего кода, в отличии от моего, мой сперва выполняет некие дейсвия, затем информирует об этом всех подписавшихся, у вас же тупо болванка которая ниче не делает но только всех информирует о сделанном, это недоработка, мне бы нормальный код, рабочий.
2. jsfiddle.net/MeX9P/1/ По вашему это нормальный класс виджета? У меня будут лишь методы. Обычный класс, простой и понятный.
ЗЫ: Вместо «недокументированной фичи» я могу использовать имена и неймспейсы, евенты будут вида:
$(element).trigger('app.start.namespace');
namespase — имя app (new App('namespace') );
1. Некие действия — это строка коммента что ли? Да, строку коммента мой код не выполняет. Досадное упущение.
2. Не понимаю что это.
3. Да, пошли извраты. $(element) появился, а там может класс вообще не взаимодействует с DOM, куда ему этот element? Уникальный неймспейс для каждого экземпляра, который не несет смысловой нагрузки, и нужен только чтобы заюзать события jQuery. В каждый колбек первым аргументом приходит jQuery Event, как повидло в борщ. А че, зато бесплатно.
Претензия к Callbacks только в том, что нужно перечислять все обработчики? Я в любом случае всегда явно описываю интерфейс класса, чтобы потом не скролить 5 экранов в поисках того, что может делать класс. Сразу понятно какие у него есть методы, свойства, и на какие события можно подписаться.
Но я это я так делаю, а если не нравится, можно сделать trait с методами on() и trigger(), и добавлять его к классам по мере надобности. Одна сточка на каждый класс, и никаких проблем связанных с jQuery Events.
2. Не понимаю что это.
3. Да, пошли извраты. $(element) появился, а там может класс вообще не взаимодействует с DOM, куда ему этот element? Уникальный неймспейс для каждого экземпляра, который не несет смысловой нагрузки, и нужен только чтобы заюзать события jQuery. В каждый колбек первым аргументом приходит jQuery Event, как повидло в борщ. А че, зато бесплатно.
Претензия к Callbacks только в том, что нужно перечислять все обработчики? Я в любом случае всегда явно описываю интерфейс класса, чтобы потом не скролить 5 экранов в поисках того, что может делать класс. Сразу понятно какие у него есть методы, свойства, и на какие события можно подписаться.
Но я это я так делаю, а если не нравится, можно сделать trait с методами on() и trigger(), и добавлять его к классам по мере надобности. Одна сточка на каждый класс, и никаких проблем связанных с jQuery Events.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Про jQuery и велосипеды — мое дополнение