Комментарии 151
Признайтесь, это статья ваша? Где-то я видел уже ее на забугорном сайте.
Если это перевод — отметьте это.
Если это перевод — отметьте это.
Ну, она написана не с нуля. Я прочитал несколько статей на эту тему, перед тем как ее писать. В основном, я использовал материалы вот этой статьи. Но я не знаю, считать ли это переводом, я значительно переработал материал.
А mabp.kiev.ua/2009/08/10/presentation-from-coffee-n-code/ пропустили-то :) Перфоманс выборки очень зависит от браузера, конкретно от поддержки querySelectorAll (querySelector).
Сейчас гораздо большей эффективности добавит разделение селектора на те, которые написаны по CSS3 правилам и на остальные. Первые выполнятся очень быстро через нативный querySelectorAll, остальные фильтранет Sizzle:
лучше выбрать так:
Ну, и не стоит забывать о совсем олдскульных трюках: в примере, где формируется DOM-строка, в IE6 все равно все будет грустно. Все маленькие строки лучше складывать в массив, а потом join-ить его. Я понимаю, что здесь речь о перфомансе jQuery, но в этом примере с водой выплеснули и ребенка:
вместо:
лучше:
Сейчас гораздо большей эффективности добавит разделение селектора на те, которые написаны по CSS3 правилам и на остальные. Первые выполнятся очень быстро через нативный querySelectorAll, остальные фильтранет Sizzle:
$("#id .class tag:visible")лучше выбрать так:
$("#id .class tag").filter(":visible")Ну, и не стоит забывать о совсем олдскульных трюках: в примере, где формируется DOM-строка, в IE6 все равно все будет грустно. Все маленькие строки лучше складывать в массив, а потом join-ить его. Я понимаю, что здесь речь о перфомансе jQuery, но в этом примере с водой выплеснули и ребенка:
вместо:
var li_items = "";
for (var i=0; i< top_100_list.length; i++)
li_items += '' + top_100_list[i] + '';
$mylist.append(li_items);
лучше:
var li_items = [];
for (var i=0; i< top_100_list.length; i++)
li_items.push('' + top_100_list[i] + '');
$mylist.append(li_items.join(''));
Спасибо за ссылочку на меня любимого ;) От себя добавлю еще что это все было про jQuery 1.3.2, а текущая 1.4.2 и в ней есть пару нюансов
>>$('#color_button') – будет выполнен максимально быстро
>>$('#content .button') – будет медленнее
Я не думаю что вы правильно сравниваете. В первом случаи вы ищете однозначно один элемент, во втором — группу, то что вы находите один элемент это частный случай.
Более того в 1.4 был оптимизирован поиск по селекторам начинающимся на # (пруфлинк), так что совет вообще не в кассу
>>3. Избегайте лишних манипуляций c DOM
я тут вот еще что накрапал для любителей делать как красиво и неправильно.
Это же касается замечания про ie6, лучше тогда уже делать вот так
$.fn.append.apply($mylist, li_items)
>>$('#color_button') – будет выполнен максимально быстро
>>$('#content .button') – будет медленнее
Я не думаю что вы правильно сравниваете. В первом случаи вы ищете однозначно один элемент, во втором — группу, то что вы находите один элемент это частный случай.
Более того в 1.4 был оптимизирован поиск по селекторам начинающимся на # (пруфлинк), так что совет вообще не в кассу
>>3. Избегайте лишних манипуляций c DOM
я тут вот еще что накрапал для любителей делать как красиво и неправильно.
Это же касается замечания про ie6, лучше тогда уже делать вот так
$.fn.append.apply($mylist, li_items)
var myElement = $('#myElement');
myElement.bind('click', function(){...});
myElement.css('border', '3px dashed yellow');
myElement.css('background-color', 'orange');
myElement.fadeIn('slow');$('#myElement').bind('click', function(){...}).css('border', '3px dashed yellow').css('background-color', 'orange').fadeIn('slow');
Да ну:)… Мне кажется автор написал это для наглядности. Ваш вариант быстрее работать не будет.
А если вы хотели сократить, то рекомендую посмотреть внимательнее метод css.
А если вы хотели сократить, то рекомендую посмотреть внимательнее метод css.
Зато весит меньше и не нуждается в доп. переменной.
По идее и работать должен быстрее, не надо каждый раз разыменовывать переменную, мизер, но всё же
с точки зрения философии jQuery, это еще и самый правильный метод. А еще я читал, что jQuery давно научился кешировать объекты, т.е.:
$('.some_class')... // поиск будет медленный
...
...
$('.some_class')... // jQuery возьмет из кеша, поиска не будет
Можно пруф?
Пока слышал, что это выдумка, ибо сделать не так то просто: надо постоянно отслеживать не добавили ли таких элементов в DOM, или не удалили старые.
Проще логику кеширования вынести из фреймворка, и просто запоминать нужные тебе элементы.
Пока слышал, что это выдумка, ибо сделать не так то просто: надо постоянно отслеживать не добавили ли таких элементов в DOM, или не удалили старые.
Проще логику кеширования вынести из фреймворка, и просто запоминать нужные тебе элементы.
Пруф не нашел :(
По поводу:
Кеширование в domManip
jQuery кэширует узлы, созданные с использованием таких методов, как jQuery("") и .after(""). Благодаря этому увеличивается производительность на страницах, на которых выполняются DOM-манипуляции со строками, использующих эти методы.
По поводу:
Кеширование в domManip
jQuery кэширует узлы, созданные с использованием таких методов, как jQuery("") и .after(""). Благодаря этому увеличивается производительность на страницах, на которых выполняются DOM-манипуляции со строками, использующих эти методы.
сорри, отправилось рано:
По поводу:
> не добавили ли таких элементов в DOM, или не удалили старые.
w3pro.ru/article/ob-izmeneniyakh-v-jquery-14-po-sravneniyu-s-predydushchei-versiei
Кеширование в domManip
jQuery кэширует узлы, созданные с использованием таких методов, как jQuery("") и .after(""). Благодаря этому увеличивается производительность на страницах, на которых выполняются DOM-манипуляции со строками, использующих эти методы.
По поводу:
> не добавили ли таких элементов в DOM, или не удалили старые.
w3pro.ru/article/ob-izmeneniyakh-v-jquery-14-po-sravneniyu-s-predydushchei-versiei
Кеширование в domManip
jQuery кэширует узлы, созданные с использованием таких методов, как jQuery("") и .after(""). Благодаря этому увеличивается производительность на страницах, на которых выполняются DOM-манипуляции со строками, использующих эти методы.
Получается при поиске никакого кеширования результатов нет.
По этому коменту в общем всё видно.
По этому коменту в общем всё видно.
Кэширования нет, в исходниках jQuery это видно
Как отметили выше, давайте дополируем:
$('#myElement')
.bind('click', function(){...})
.css({
'border' : '3px dashed yellow',
'background-color' : 'orange'
}).fadeIn('slow');
Логично предположить что кликнутый элемент становится активным. Соответсвенно можно упростить addClass/removeClass. В таком случае будет правильно разделены стилизация и функциональность.
$('#myElement')
.bind('click', function(){...})
.addClass('activeState')
.fadeIn('slow');
Да, и при анимациях рекомендую использовать .stop() а потом .fadeIn() или animate()
СSS применялось просто так, а не по клику, оно же не в обработчике — это поправка к Вашему описанию
А так, я тоже за вынос правил оформления через класс в CSS
А так, я тоже за вынос правил оформления через класс в CSS
$('#myElement')
.click( function(){...} )
.addClass('activeState')
.fadeIn('slow');
.click( function(){...} )
.addClass('activeState')
.fadeIn('slow');
Я немного подправил этот код в статье. Я хотел показать, что если на протяжении одного блока кода, вам необходимо работать с одними и теми же элементами, то их кеширование приведет к экономии ресурсов. То есть, совсем не обязательно, что обращение к этим элементам будет происходить друг за другом. Исправил на такой вариант:
var myElement = $('#myElement');
. . .
myElement.bind('click', function(){...});
. . .
myElement.css('border', '3px dashed yellow');
. . .
myElement.fadeIn('slow');
Хм, был удивлен 2 пунктом, меня неоднократно убеждали в том что jQuery хорош именно тем, что кеширует результаты поиска.
Сейчас сделал небольшой скрипт для тестирования скорости.
выполняется за три секунды, а
за треть секунды. То есть разница примерно в 10 раз. Однако, при поиске по идентификатору, разница только в два раза.
for(var i = 0; i<5000; i++)
$("li.stop").attr("class");
выполняется за три секунды, а
var el = $("li.stop");
for(var i = 0; i<5000; i++)
el.attr("class");
за треть секунды. То есть разница примерно в 10 раз. Однако, при поиске по идентификатору, разница только в два раза.
Как всегда одно и тоже из серии: «Бла-бла-бла для чайников». И ошибки все старые. Вот вы в код-то самой jquery заглядвали? Откуда вы взяли, что поиск будет быстрее по идентификатору? Там по коду вначале идет проверка на то, есть ли вообще селектор (не равен ли он пустой строке), далее не DOM-элемент ли, далее не равен ли селектор строке «body» с отсутствующим контекстом, а уж после того только начинается анализ строки селектора, если предыдущие проверки не сработали. Из этого можно сделать вывод, что тот же тег body найдется быстрее по названию, нежели по id.
Поправка, проверка на наличие селектора: не равне ли он пустой строке / null / undefined.
Нет, код jquery мне разбирать еще не доводилось. Сейчас сделал скрипт для тестирования, элемент body находится действительно быстрее, процентов на 20, в нескольких других случаях, поиск по идентификатору чуть быстрее поиска по тегам (разница около 10%).
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Неправда. Эта функция есть отнюдь не во всех браузерах.
Насколько я знаю этой функции вообще нет в браузерах, поскольку она только планируется в HTML5:
www.w3.org/TR/html5/dom.html#dom-document-getelementsbyclassname
www.w3.org/TR/html5/dom.html#dom-document-getelementsbyclassname
НЛО прилетело и опубликовало эту надпись здесь
Вообще-то наверное чуток соврал:
* // если есть родная фукнция, используем ее
Значит предпологается что где-то родная функция есть… =)
01 if(document.getElementsByClassName) { // если есть родная фукнция, используем ее *
02 getElementsByClass = function(classList, node) {
03 return (node || document).getElementsByClassName(classList) // вызываем метод getElementsByClassName нужного узла.
04 // если указан node, то будет произведен поиск в нем, иначе во всем документе
05 }
06
07 } else { // если родной функции нет, то будем обходить DOM
08 getElementsByClass = function(classList, node) {
09 var node = node || document, // узел, в котором ищем
10 list = node.getElementsByTagName('*'), // выбираем все дочерние узлы
11 length = list.length, // количество дочерних узлов
12 classArray = classList.split(/\s+/), // разбиваем список классов
13 classes = classArray.length, // длина списка классов
14 result = [], i,j
15 for(i = 0; i < length; i++) { // перебираем все дочерние узлы
16 for(j = 0; j < classes; j++) { //перебираем все классы
17 if(list[i].className.search('\\b' + classArray[j] + '\\b') != -1) { // если текущий узел имеет текущий класс
18 result.push(list[i]) // запоминаем его
19 break // прекращаем перебор классов
20 }
21 }
22 }
23
24 return result // возвращаем набор элементов
25 }
26 }
* This source code was highlighted with Source Code Highlighter.* // если есть родная фукнция, используем ее
Значит предпологается что где-то родная функция есть… =)
Конечно дико извиняюсь — но вот в спецификациях HTML4 так сразу не нашел. Если можно ссылочку на w3c. Если ссылочки не будет — функцию нельзя назвать нэтивной.
НЛО прилетело и опубликовало эту надпись здесь
Совет не про производительность, а просто нотация, чтобы отличать джиквери объекты от обычных: начинать название элемента с $.
var $inputs = $('#myForm input');А какже context? $('#elmId', context)
спасибо, никогда не задумывался над этим
А еще += очень медленная операция =) лучше с массивом работать… Это к jQuery не относится, просто в манипуляциях с ДОМ Вы использовали эту штуку…
И я бы добавил отсебятыны: если просто нужно получить элемент по айди и сделать с ним что-то, то наверно даже быстрее будет найти их стандартными функциями, и отдать в $ найденный массив элементов, т.к jQuery не будет в этом случае парсить строку и разбирать на элементы для поиска а сразу поймет что получает набор элементов и просто добавит массиву своих методов
И я бы добавил отсебятыны: если просто нужно получить элемент по айди и сделать с ним что-то, то наверно даже быстрее будет найти их стандартными функциями, и отдать в $ найденный массив элементов, т.к jQuery не будет в этом случае парсить строку и разбирать на элементы для поиска а сразу поймет что получает набор элементов и просто добавит массиву своих методов
Немного добавлю от себя (правда, это больше касается не эффективности, а удобства разработки).
Названия всех jQuery-объектов можно начинать с буквы «j», например,
Хорошо помогает ориентироваться, и не путать обычные DOM-переменныес jQuery-обёртками .
Названия всех jQuery-объектов можно начинать с буквы «j», например,
jMyElement, jInputs, jMyList и так далее.Хорошо помогает ориентироваться, и не путать обычные DOM-переменные
Практика показывает что если человек работает с jQuery, то все DOM-переменные получаются с применением jQuery и значит они уже расширенные новыми методами
могу ошибаться, но вроде бы пункт 2 уже не актуален, джекуэри кеширует ранее найденные элементы сам
13 ноября 2009: «Как увеличить скорость работы jQuery скрипта»
http://habrahabr.ru/blogs/jquery/75103/
Даже начинается с того же примера. :) Видимо, основана на то же статье, что автор этой брал за основу.
http://habrahabr.ru/blogs/jquery/75103/
Даже начинается с того же примера. :) Видимо, основана на то же статье, что автор этой брал за основу.
var top_100_list = [...]; // содержимое новых элементов
var new_ul = "";
- ' + top_100_list[i] + '
$mylist.replaceWith(li_items);
В данном коде ошибка. Вместо li_items везде нужно использовать new_ul.
Забыл код в <pre> упаковать )
В данном коде ошибка. Вместо li_items везде нужно использовать new_ul.
var top_100_list = [...]; // содержимое новых элементов var new_ul = "<ul id='mylist'>"; // вставляемый html-текст $mylist = $('#mylist'); // необходимый список for (var i=0; i< top_100_list.length; i++) li_items += '<li>' + top_100_list[i] + '</li>'; new_ul += "</ul>"; $mylist.replaceWith(li_items);
В данном коде ошибка. Вместо li_items везде нужно использовать new_ul.
Самый эффективный способ использования — вообще не использовать jQuery. В больших проектах все равно толку мало от write less, приходится все равно do more.
Не факт, как ни крути, а работать с группами элементов с помошью библиотек проще, да и написанной работы в них хватает чтоб избавить человека от лишних фантазий, да и протестированы библиотеки лучше чем вновь написанный код
Работать с группами элементов при помощи библиотек проще. Но при чем тут JQ? Это всего лишь одна из библиотек, которая использует только определенный способ работы с элементами. На это я и акцентировал внимание. Мышление, заточенное только под JQ, не дает кодеру плюсов. Многие «суперскрипты» можно сделать без JQ в 10 раз проще и эффективнее
Допустим, у вас есть задание, сделать переключатель видимости элемента
Состояние 1
[показать контент]
Состояние 2
[спрятать контент]
| Контент блока 1 |
Как вы будете реализовывать данный код?
Допустим, у вас есть задание, сделать переключатель видимости элемента
Состояние 1
[показать контент]
Состояние 2
[спрятать контент]
| Контент блока 1 |
Как вы будете реализовывать данный код?
Причем тут задание? Человек не знаючий чистый JS не будет нормально работать с jQ, это очевидно, просто в библиотеках полно кода который уже написали, и его не надо будет писать заново, но он может помочь
Прошу еще раз внимательно перечитать мое сообщение. Я разве спорю с хоть одним из ваших очевидных постулатов? Я спорю с тем, что jQ не дает выигрыша при использовании в больших проектах. И проблема тут не в готовости кода, а в подходах, которые используются в jQ. Они убивают желание думать своей головой, а не абстракциями фреймворка. И пример я приводил сугубо для того, чтобы показать ошибочность логики построения решения.
1 — Ваш пример глупый
2 — Библиотеки не убивают желание думать головой, а лишь избавляют от некоторых проблем
3 — пишите на Си вебсайты, там надо больше думать
как-то так
2 — Библиотеки не убивают желание думать головой, а лишь избавляют от некоторых проблем
3 — пишите на Си вебсайты, там надо больше думать
как-то так
1. Обоснование я услышу?
2. Библиотека обладает определенным функционалом. Использование функционала ограничивает варианты решения задач.
3. А Си при чем тут?
2. Библиотека обладает определенным функционалом. Использование функционала ограничивает варианты решения задач.
3. А Си при чем тут?
1 Напишите решение на чистом JS, я вам приведу более компактное решение на любой библиотеке
2 Функционал библиотек при желании можно увеличить, для этого нужна всего одна строка + своя функция, и она будет работать как с одним элементом, так и с набором данных
3 Си заставит вас от мнения «убивают желание думать своей головой», потому как заставит Вас думать
2 Функционал библиотек при желании можно увеличить, для этого нужна всего одна строка + своя функция, и она будет работать как с одним элементом, так и с набором данных
3 Си заставит вас от мнения «убивают желание думать своей головой», потому как заставит Вас думать
Не проблема
Приводите более компактное решение. Я закрою глаза, что фреймворк весит немало килобайт.
<div>
<a href="#" onclick=«this.parentNode.className='swapOn'» class=«swapBlock1»>[показать контент]</a>
<a href="#" onclick=«this.parentNode.className=''» class=«swapBlock2»>[спрятать контент]</a>
<div class=«swapBlock2»>Контент блока 1</div>
</div>
.swapBlock2, .swapOn .swapBlock1 {display: none }
.swapOn .swapBlock2 { display: block }
Приводите более компактное решение. Я закрою глаза, что фреймворк весит немало килобайт.
Нативный инлайновый JS-код, который ещё и сбрасывает хеш страницы при клике на ссылки… фу, бяка.
Если вы про недостающий return false, то засчитаю как повод придраться.
Я много слышал восторженных откликов про ненавязчивый JS, но на простой вопрос, на каком элементе в данной конструкции навешен обработчик click, мне никто и не ответил
Вот открываете вы файл, и не можете ответить на столь простой вопрос. Для ответа на этот простой вопрос, вам необходимо открывать как минимум еще один файл. Иногда даже больше. Эффективность поиска ошибки просто на высоте! Непонятно, почему круто, но все говорят, что это несомненно круто.
Я много слышал восторженных откликов про ненавязчивый JS, но на простой вопрос, на каком элементе в данной конструкции навешен обработчик click, мне никто и не ответил
<ul class=«menu»>
<li class=«menuItem»><span class=«menuTitle»>Menu item1</span></li>
<li class=«menuItem»><span class=«menuTitle»>Menu item2</span></li>
</ul>
Вот открываете вы файл, и не можете ответить на столь простой вопрос. Для ответа на этот простой вопрос, вам необходимо открывать как минимум еще один файл. Иногда даже больше. Эффективность поиска ошибки просто на высоте! Непонятно, почему круто, но все говорят, что это несомненно круто.
это говно, а не решение.
У него есть недостатки, это несомнено, но вы сначала подумайте над достоинствами. Хаять можно любой код, даже ваш
я не могу увидеть достоинства в скрипте, вписанном в html атрибуты, завязанный на классы 1,2,3. если а 1000 элементов?
если в Вашем примере врапперу проставить класс .toggler (ниже Вы сами пишите про масштабируемость), обоим ссылкам поставить класс .toggle, вторую ссылку и блок с контентом обернуть в div.content, то, убрав все остальные классы имеем:
$('.toggler .toggle').click(function() {
$(this).parents('.toggler:first').toggleClass('hidden');
});
И все. Ну и стили:
.hidden .content, .toggler .toggle { display: none; }
.hidden .toggle, .content .toggle { display: inline; }
.toggle { cursor: pointer; } /* :) */
если в Вашем примере врапперу проставить класс .toggler (ниже Вы сами пишите про масштабируемость), обоим ссылкам поставить класс .toggle, вторую ссылку и блок с контентом обернуть в div.content, то, убрав все остальные классы имеем:
$('.toggler .toggle').click(function() {
$(this).parents('.toggler:first').toggleClass('hidden');
});
И все. Ну и стили:
.hidden .content, .toggler .toggle { display: none; }
.hidden .toggle, .content .toggle { display: inline; }
.toggle { cursor: pointer; } /* :) */
<div>
<a href="#" id=«shoHide»>Показать/скрыть контент</a>
<div class=«swapBlock2» id=«content»>Контент блока 1</div>
</div>
Я очень не люблю ЖС в тегах, на много проще им пользоваться в одном файле
Пример не такой как Вы хотели, но я думаю Вы суть поняли. Чтоб надпись «показать/скрыть контент» менялась, добавится всего одна строчка.
Код с библиотекой приятней и понятней, и нет каши между HTML и JS
<a href="#" id=«shoHide»>Показать/скрыть контент</a>
<div class=«swapBlock2» id=«content»>Контент блока 1</div>
</div>
$('#showHide').click(
function(){
$('#content').toggle()
}
)
Я очень не люблю ЖС в тегах, на много проще им пользоваться в одном файле
Пример не такой как Вы хотели, но я думаю Вы суть поняли. Чтоб надпись «показать/скрыть контент» менялась, добавится всего одна строчка.
Код с библиотекой приятней и понятней, и нет каши между HTML и JS
Ха, скопируйте свой код два раза. Упс. Масштабируемость на высоте.
Зачем мне его копировать 2 раза?
Так Вас устроит?
$('#showHide').click(
function(){
$(this).parent.toggleClass('swapOn')
}
)Так Вас устроит?
Потому что код можно повторно использовать. Ваш код нельзя.
Вполне можно:
Я только что скопировал свой код 3 раза, я могу массив айдишников сделать, я могу всем нужным элементам дать бутафорский класс и по нему показывать скрывать… Вы такого не можете на чистом JS, вернее можете, но это займет время и код.
$('#showHide, #otherShowHide, #thirdShowHide').click(
function(){
$(this).parent().toggleClass('swapOn')
}
)Я только что скопировал свой код 3 раза, я могу массив айдишников сделать, я могу всем нужным элементам дать бутафорский класс и по нему показывать скрывать… Вы такого не можете на чистом JS, вернее можете, но это займет время и код.
Массив айдишников требует менеджера айдишников, чтобы ваш код продолжал функционировать. Мне стоит добавить всего одну примитивную функцию, которая бы искала парента по имени класса, и на этом простом приеме я бы сделал огромный шаг к масштабированию кода. Еще понадобится примитивная функция, которая бы добавляла имя класса или удаляла его у ноды без глобальной перезаписи.
Сделав всего две простые функции, я могу их потом использовать везде, много раз.
Сделав всего две простые функции, я могу их потом использовать везде, много раз.
// put here selector to enable folding
var items = ['#id1', '#id2', '#id3', '#id4']
$(items.join(', ')).click(
function(){
$(this).parent().toggleClass('swapOn')
}
)Еще варианты? Я сделал универсальный менеджер для сворачивания элементов
А теперь подумайте, как использовать ваш код при том же подходе, что и в Clipperz
Если честно, я не понял о чем Вы.
О том, что менеджер идентификаторов должен пронизывать весь ваш код, да еще и код серверных скриптов. Там все данные показываются на одной странице, поэтому нужно следить за тем, чтобы разные модули не пытались использовать одинаковые идентификаторы, что приведет к просто непредсказуемуму результату. Вы будете наворачивать код на своей стороне, на стороне сервера, только ради идентификаторов? Это очень плохая затея, которая все равно закончится багами.
А не проще идентификаторы давать вида:
modulename_blockname? они не будут пересекаться и будет понятно что куда относится
modulename_blockname? они не будут пересекаться и будет понятно что куда относится
:) Это помогает, но не всегда.
В одном и том же модуле могут быть два одинаковых элемента.
Проблема с префиксами поджидает еще в другом месте. Если два модуля будут использовать код третьего, то они получат… два одинаковых идентификатора от третьего модуля. Или получат два разных, а нужно использовать один одинаковый.
Проблема кроется в самом факте наличия идентификатора. В проектах с одной страницей и подгружаемыми модулями нужно избавляться от них. А это уже другая философия
В одном и том же модуле могут быть два одинаковых элемента.
Проблема с префиксами поджидает еще в другом месте. Если два модуля будут использовать код третьего, то они получат… два одинаковых идентификатора от третьего модуля. Или получат два разных, а нужно использовать один одинаковый.
Проблема кроется в самом факте наличия идентификатора. В проектах с одной страницей и подгружаемыми модулями нужно избавляться от них. А это уже другая философия
У вас плохой код, я это могу определить даже не видя его. Раз на стадии проектирования такой каламбур, то код небось тоже такой же шифрованный.
Если я показываю блок «users» то он должен у меня быть один, и ниипет меня там кто что использует, другой модуль поиспользовал мой, и вывед все то что наиспользовал со своим идентификатором «othermodule». Мне не нужна каша в коде
Если я показываю блок «users» то он должен у меня быть один, и ниипет меня там кто что использует, другой модуль поиспользовал мой, и вывед все то что наиспользовал со своим идентификатором «othermodule». Мне не нужна каша в коде
В общем мы полезли не в ту степь. Я предлагаю Вам идеальный вариант для фолдинга: делаем класс болванку, и используем мой код, если нужно сворачивать блок, даем ему этот класс, все, проблемы нет, можно без всяких конфликтов использовать мой код с пустым классом. Если вас не устраивает это решение, используйте свое дальше, а я буду использовать све, на этом и разойдемся
Вы в глаза не видели моего кода, но уже осмеливаетесь заявлять, что он плохой? Каша не у меня в голове, каша возникает у многих программистов, когда они не видят проблем будущего.
Второй вопрос туда же. Что вы будете делать, когда вам вдруг нужно будет включать не один блок, а два?
И третий вопрос, вы не выполнили условие задания, вы сделали одну кнопку, а нужно две.
Зачем мне кнопка «показать блок» когда блок показан?
Внимательно изучите исходное задание.
Я разработчик а не бот, я могу предложить вариант лучше и заказчик с 99% вероятности согласится со мной в даной ситуации
Вот и подтверждение того, что вам проще изменить задачу под возможности фреймворка, чем реализовать 1 к 1 поставленную задачу.
Нет, задачу я меняю не под возможности фреймворка, а под удобство использования. Хорошее UI — залог удобства использования проекта в целом. Библиотека здесь абсолютно ни при чем, второй код будет прекрасно работать с вашим примером
это что за скриншот? о0
Полагаю, что Isis облегчил taliban жизнь, заблокировав для него habrahabr.ru/blogs/jquery/
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Читайте между строк. Никто не мешает вам сделать набор утилит по решению ваших задач. Большинство функционала JQ не нужно для решения 80% задач. Но пост не об этом. Вы должны заботиться не только про стандартизацию разработки, но и за уменьшение ошибок в будущем коде, уменьшение стоимости будущей разработки. Вы должны эффективно использовать инструмент, а не надеяться, что наличие инструмента уже добавляет вам эффективности.
НЛО прилетело и опубликовало эту надпись здесь
Скажите, а защищает ли вас фреймворк от ошибок, которые допускает разработчик при использовании этого самого фреймворка?
Если разработчик не внимателен, то фреймворк не стоит винить
НЛО прилетело и опубликовало эту надпись здесь
Ты не прав. Я как-то работал с мегабайтами JS кода, сокращенными в несколько раз при адаптации jQuery.
Я работаю с кодом, который был написан еще 3 года назад, используется по всему проекту, и ни разу еще не был переписан. Повтор использования кода достигает от 60 до 90%. Вы сократили в несколько раз объем кода, но сократили ли вы одновременно с этим количество ошибок? Достигли большей понимаемости кода? Проще ли вам изменять продукт с этим кодом? Остался ли уровень количества переделок на том же уровне, или стало лучше?
Подумайте над эффективностью инструментов.
Подумайте над эффективностью инструментов.
я для ЛибКанваса так и делал первую неделю. Потом посмотрел, понял, что я изобретаю Мутулз и плюнул.
Где-где, а в ЖС библиотеки сейчас прекрасны и нету смысла их не использовать
Где-где, а в ЖС библиотеки сейчас прекрасны и нету смысла их не использовать
1.2 Пункт не верен, в данном примере $('#id input') будет работать медленнее чем просто $('input'), для ускорения необходимо указывать контекст, для этого и служит второй параметр: $('input', $('#id')[0]), или $('#id').find('input');
1.3 Тоже неверное рассуждение, будут найдено множество .button потом к нему применен фильтр по тэгу, сам же селектор вида tag.class будет работать быстрее только относительно браузеров у которых нет поддержки функции getElementsByClassName (IE <= 7 кажись)
2. jQuery не кеширует селекторы, для поиска используется движок Sizzle — в нем нет механизма кеширования.
Еще хороший пример:
Лучше
4. Делегирование описано без упоминания метода delegate?
1.3 Тоже неверное рассуждение, будут найдено множество .button потом к нему применен фильтр по тэгу, сам же селектор вида tag.class будет работать быстрее только относительно браузеров у которых нет поддержки функции getElementsByClassName (IE <= 7 кажись)
2. jQuery не кеширует селекторы, для поиска используется движок Sizzle — в нем нет механизма кеширования.
Еще хороший пример:
$('#selector').click(function(){
$(this).find('.class')....;
});Лучше
$('#selector').click(function(){
$('.class', this)....;
});4. Делегирование описано без упоминания метода delegate?
1.2. ты померил чтобы так утверждать?
Мне достаточно знать как работает Sizzle, чтобы так утверждать.
и как он работает?
Насколько помню к релизу jQuery 1.4 Sizzle оптимизировали под часто используемые селекторы, в том числе и с #id в начале — они должны приводить к поиску в контексте
Такое может быть. В этом случае лучше указывать версию JQuery, так как 1.3 много где используется, и оптимизируя без учета версии получим наоборот тормоза.
Посмотрел в исходниках, проверка на id железная quickExpr = /^[^<]*(<[\w\W]+>)[^>]*$|^#([\w-]+)$/ (html или id), так что оптимизации селекторов с #id не нашел.
Этот код из jQuery, а копать надо в Sizzle
В самом Sizzle имеется проверка и оптимизация на #id в начале селектора
// Take a shortcut and set the context if the root selector is an ID
// (but not if it'll be faster if the inner selector is an ID)
if ( !seed && parts.length > 1 && context.nodeType === 9 && !contextXML &&
Expr.match.ID.test(parts[0]) && !Expr.match.ID.test(parts[parts.length — 1]) ) {
var ret = Sizzle.find( parts.shift(), context, contextXML );
context = ret.expr? Sizzle.filter( ret.expr, ret.set )[0]: ret.set[0];
}
Т.е. сперва ищется элемент по id, затем он становится контекстом, в котором происходит дальнейший поиск. Т.е. конструкция вида $('#id tagName') работает после разбора селектора как $('tagName', '#id'), однако тратится какое-то время на сам разбор селектора с помощью регулярных выражений и другие операции. Можете протестировать — скорость отличаться будет, ну, грубо на несколько процентов, в зависимости от сложности самой выборки и т.п.
Но это относится, например, к FF 3.0, где нет нативной поддержки querySelectorAll.
Другое дело, когда вы используете «современный» браузер аля Chrome или FF версии 3.6+, где при указании селектора вида $('#id tagName') за работу берется сам движок браузера, который делает по понятным причинам это достаточно быстро. Однако если вы в современном браузере укажете $('tagName', '#id'), то тут уже в работу пойдет Sizzle, который как бы он там не оптимизировал селекторы, все равно работает медленнее, чем querySelectorAll.
Вывод: «старый» браузер — быстрее $('tagName', '#id'), новый — быстрее $('#id tagName').
Можете просто элементарно замерить скорость выборки на страничке.
// Take a shortcut and set the context if the root selector is an ID
// (but not if it'll be faster if the inner selector is an ID)
if ( !seed && parts.length > 1 && context.nodeType === 9 && !contextXML &&
Expr.match.ID.test(parts[0]) && !Expr.match.ID.test(parts[parts.length — 1]) ) {
var ret = Sizzle.find( parts.shift(), context, contextXML );
context = ret.expr? Sizzle.filter( ret.expr, ret.set )[0]: ret.set[0];
}
Т.е. сперва ищется элемент по id, затем он становится контекстом, в котором происходит дальнейший поиск. Т.е. конструкция вида $('#id tagName') работает после разбора селектора как $('tagName', '#id'), однако тратится какое-то время на сам разбор селектора с помощью регулярных выражений и другие операции. Можете протестировать — скорость отличаться будет, ну, грубо на несколько процентов, в зависимости от сложности самой выборки и т.п.
Но это относится, например, к FF 3.0, где нет нативной поддержки querySelectorAll.
Другое дело, когда вы используете «современный» браузер аля Chrome или FF версии 3.6+, где при указании селектора вида $('#id tagName') за работу берется сам движок браузера, который делает по понятным причинам это достаточно быстро. Однако если вы в современном браузере укажете $('tagName', '#id'), то тут уже в работу пойдет Sizzle, который как бы он там не оптимизировал селекторы, все равно работает медленнее, чем querySelectorAll.
Вывод: «старый» браузер — быстрее $('tagName', '#id'), новый — быстрее $('#id tagName').
Можете просто элементарно замерить скорость выборки на страничке.
Надо было страничку обновить :(
Насчет же querySelectorAll — то лучше бить запрос на куски, если есть сомнения, что querySelectorAll его не прохавает, к примеру при использовании кастомных фильтров.
Насчет же querySelectorAll — то лучше бить запрос на куски, если есть сомнения, что querySelectorAll его не прохавает, к примеру при использовании кастомных фильтров.
Да, во всём нужен разумный подход. Но это уже специфический вопрос очень тонкой оптимизации, когда экономия идёт на миллисекунды, мы не будем сейчас об этом.
Сам я кастомные фильтры не люблю, вернее, не использую почти никогда, потому что нет необходимости, в большинстве случаев получается все делать без них — простота — залог успеха.
Сам я кастомные фильтры не люблю, вернее, не использую почти никогда, потому что нет необходимости, в большинстве случаев получается все делать без них — простота — залог успеха.
Накопал:
Если ищем в рамках контекста Document, и первым идет #id (и не идет при этом последним), то в качестве контекста таки будет использоваться элемент #id
// Take a shortcut and set the context if the root selector is an ID
// (but not if it'll be faster if the inner selector is an ID)
if ( !seed && parts.length > 1 && context.nodeType === 9 && !contextXML &&
Expr.match.ID.test(parts[0]) && !Expr.match.ID.test(parts[parts.length - 1]) ) {
var ret = Sizzle.find( parts.shift(), context, contextXML );
context = ret.expr ? Sizzle.filter( ret.expr, ret.set )[0] : ret.set[0];
}
Если ищем в рамках контекста Document, и первым идет #id (и не идет при этом последним), то в качестве контекста таки будет использоваться элемент #id
Как показала практика, переход с 1.3 на 1.4 совершенно безболезненнен обычно. Ну и обычно подразумевается актуальная версия, если не указана иная
У вас дельные замечания.
Единственное п. 2 разницы между $(this).find и $('.class', this) нет.
// HANDLE: $(expr, context)
// (which is just equivalent to: $(context).find(expr)
} else {
return jQuery( context ).find( selector );
}
Единственное п. 2 разницы между $(this).find и $('.class', this) нет.
// HANDLE: $(expr, context)
// (which is just equivalent to: $(context).find(expr)
} else {
return jQuery( context ).find( selector );
}
> в данном примере $('#id input') будет работать медленнее чем просто $('input')
судя по этой статье vremenno.net/js/how-to-test-and-optimize-scripts/ всё таки будет быстрей ) хотя возможно так: $('#id').find('input'); будет ещё быстрей.
судя по этой статье vremenno.net/js/how-to-test-and-optimize-scripts/ всё таки будет быстрей ) хотя возможно так: $('#id').find('input'); будет ещё быстрей.
Для 4 существует live и delegate
«Как известно, стандартные события javascript, вызванные на каком-либо элементе, затем вызываются на всех его потомках» исправьте на «предках».
не знаю автор тырил где-то статью эту по частям, или сам натестился )
но вот есть например такая статья habrahabr.ru/blogs/jquery/52201/
ей уже полтора года
но вот есть например такая статья habrahabr.ru/blogs/jquery/52201/
ей уже полтора года
А кэшировать кто будет?
jQuery.root = jQuery(document);
$$ = function(sel) {
return jQuery.root.find(sel);
};
И не надо лишний раз создавать объект jQuery, во многих местах можно на чистом js писать. Простейший пример:
$('#spam').bind('click', function() {
$(this).attr('id', 'eggs');
});
медленнее, чем
$('#spam').bind('click', function() {
this.id = 'eggs';
});
jQuery.root = jQuery(document);
$$ = function(sel) {
return jQuery.root.find(sel);
};
И не надо лишний раз создавать объект jQuery, во многих местах можно на чистом js писать. Простейший пример:
$('#spam').bind('click', function() {
$(this).attr('id', 'eggs');
});
медленнее, чем
$('#spam').bind('click', function() {
this.id = 'eggs';
});
Пункт 4.
в КОРНЕ непрактичен. Вот вам пример разметки выпадающего меню с подпунктами:
Кликнуть можно на:
#myList > ul
#myList > ul > li
#myList > ul > li > a
#myList > ul > li > ul
…
event.target может стать чем-угодно, надо добавлять геморроя с проверкой. А выгода от производительности ничтожна.
$('#myList').click(function(event){
$(event.target).addClass('clicked'); // добавим нажатому элементу класс clicked
});
в КОРНЕ непрактичен. Вот вам пример разметки выпадающего меню с подпунктами:
<ul id="#myList">
<li>
<a> Menu 1 </a>
</li>
<li>
<a> Menu 2 </a>
</li>
<li>
Menu 3
<ul>
<li>
<a> Submenu 3-1 </a>
</li>
</ul>
</li>
</ul>
Кликнуть можно на:
#myList > ul
#myList > ul > li
#myList > ul > li > a
#myList > ul > li > ul
…
event.target может стать чем-угодно, надо добавлять геморроя с проверкой. А выгода от производительности ничтожна.
Насчет пункта 4:
А не проще использовать $('#myList li').live('click', function(){$(this).addClass('clicked')});?
Он навешивает всего один обработчик на страницу. И сам определяет элемент по которому кликнули. Скорость работы такая же как и у вас только все логично и без проверок.
А не проще использовать $('#myList li').live('click', function(){$(this).addClass('clicked')});?
Он навешивает всего один обработчик на страницу. И сам определяет элемент по которому кликнули. Скорость работы такая же как и у вас только все логично и без проверок.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Правила эффективного использования jQuery