по коду - не стоит делать гигантских двумерных функций
|
Цитата:
|
PeaceCoder,
а вы добавляли элементы в DOM вручную или использовав функции из Карбона? Просто на этот счёт во всех функциях из DOM-модуля есть функция автоматического обновления кэша, соответственно таких проблем возникнуть не должно. Над комбинаторами подумаю, возможно будет проще сделать посимвольный разбор строки в данном случае, как я делал в getByPseudo(). Спасибо за замечания :) tenshi, как я уже написал на своём сайте, я не собираюсь делать очередной jQuery, и тем более модернизировать его. Почему? Не люблю ковыряться в чужом навороченном коде. Я как-то пытался понять, а как же оно там всё устроено... И решил, что проще написать свою библиотеку. |
Цитата:
|
Ну, можно ещё пошаманить с MutationEvents.
|
Цитата:
|
Цитата:
|
Cr@ZyBoY,
Кстати спасибо за идею разделения getByCombinators. Если я на верном пути, а это кажется так, то вроде допер как быстро выбрать нужные элементы не затрачивая практически времени. ща буду соединять логику jQ и твою... |
Array.prototype.inArray = function(value) {
var i = 0, ii;
while (ii = this[i++]) {
if (ii === value) return true;
}
return false;
};
перезапись переменной (ii = thi) довольно медленная операция (относительно) и в данном случае происходит при каждой итерации цикла, можно легко избавиться от нее. Вторая перезапись (i++) срабатывает лишний раз в последней итерации цикла. Вообще все циклы очень не оптимизировано написаны. CarbonJS.onDOMready = function(func) {
var init = function() {
if (arguments.callee.done) return;
....
ужасно написано: - отдельный Interval для каждого вызова, можно обойтись одним. - целевая функция должна вызываться в контексте document так как является обработчиком события DOMContentLoaded (в идеале) которое принадлежит документу. - способ для отслеживания readyState в WebKit давно не имеет смысла, версиями браузеров для которых он придуман уже давно вообще никто не пользуется. - вызов CarbonJS.onDOMready после onload уходит в пустоту, может это и правильно, но обычно это не так, кроме того при этом останутся Interval-ы которые уже никогда не будут сброшены. - перезапись window.onload. - вместо defer лучше использовать doScroll. Мой старый вариант с defer: http://javascript.ru/forum/events/60...d-i-defer.html Octane там объяснил чем doScroll лучше. window.onunload = function() { // Чтобы избежать утечек памяти во всеми любимом браузере, удаляем вручную все установленные обработчики событий
while (CarbonJS.events.length > 0) Q(CarbonJS.events[0].obj).removeEvent(CarbonJS.events[0].evt);
};
если я через addEvent назначу событие onunload, то unload удаляющий все события вероятно сработает раньше моего (мой unload удалится и не сработает), window.onunload тоже занят, и как мне теперь свой unload поставить? cl = cl.split(" "); // Чтобы удалить класс, сначала разбиваем className на массив значений
разделителем имен может быть любой пробельный символ, а не только пробел. while (++i < cl.length) ncl += cl[i]; // и перезаписываем className Array#join //---------------- Вывод: при максимально беглом осмотре двух модулей множество стандартных ошибок, что будет если я детально стану разбирать? Сильно не оптимизированный код, особенно циклы, множество спорных решений. |
PeaceCoder,
да не за что. Кстати, интересно поглядеть на ваш движок. Kolyaj говорил, что он где-то в соседней теме, но я что-то не нашёл... Riim, на мой выбор такого типа циклов повлияла вот эта статья - http://habrahabr.ru/blogs/yass/49679/ ("Перебор массива"). Если вы знаете более быстрый способ - пожалуйста, я его рассмотрю и протестирую. Про onDOMready: это отголоски моей первой библиотеки 2-летней давности, код я пересмотрю. Большую часть функций из модуля utilities я тоже буду переписывать, просто ещё руки не дошли. Насчёт циклов я своё мнение уже сказал. Если вас не затруднит, посмотрите подробнее другие модули. |
| Часовой пояс GMT +3, время: 20:10. |