Комментарии 10
по-моему у вас получился какой-то бред.
во первых, я смутно себе представляю ситуацию, когда нужно заполнить большое количество блоков одинаковыми dom-фрагментами. зачем такое может понадобиться?
во вторых, и ежу понятно, что производительнее сначала создать полный dom-фрагмент и затем клонировать его в каждый отдельный блок, чем каждый раз делать dom-фрагмент заново для каждого блока. изобретаете велосипеды?
каким местом сюда относится DocumentFragemnt совершенно не ясно...
во первых, я смутно себе представляю ситуацию, когда нужно заполнить большое количество блоков одинаковыми dom-фрагментами. зачем такое может понадобиться?
во вторых, и ежу понятно, что производительнее сначала создать полный dom-фрагмент и затем клонировать его в каждый отдельный блок, чем каждый раз делать dom-фрагмент заново для каждого блока. изобретаете велосипеды?
каким местом сюда относится DocumentFragemnt совершенно не ясно...
+1
Если вы не сталкивались с такими задачами то это не значит что их нет. Одно заполнение карты маркерами чего стоит, когда на карту приходится загружать по несколько сотен или тысяч маркеров, и необходимо быстро модифицировать DOM дерево. А потом если сразу переключить на вывод вектора методами VML или SVG на тойже карте и убрать эти несколько сотен маркеров и показать к примеру маршруты общественного транспорта коих может быть также несколько сотен, или загрузить маплет который частично модифицирует интерфейс карт. Для юзера это должно работать быстро и прозрачно. Карты один из ярких примеров когда идет активная модификация DOM дерева, причем все должно работать без ошибок и быстро.
0
Кстати давно заметил такую интересную вещь. Когда делаешь
node = parent.removeChild(some_child);
То во всех браузерах node.parentNode равен null. В то время как в IE node.parentNode ссылается на DocumentFragment. Можно проверить таким кодом:
Только в IE выдаст 11 (что соответствует DOCUMENT_FRAGMENT_NODE).
По этой причине, к примеру, нельзя проверить находится ли элемент в документе или нет (при условии что он может быть либо в документе, либо вне его - то есть при удалении из документа он не вложен в другой элемент) является неверным (точнее не работает в IE):
if (node.parentNode == null)
...
Если быть совсем точным, то parentNode равен null только после создания элемента (document.createElement), во всех остальных случаях он всегда ссылается на другие узлы (DocumentFragment тоже узел). Вот такой занятный DOM в исполнении IE :) Хотя может быть это разумно, кто знает?
node = parent.removeChild(some_child);
То во всех браузерах node.parentNode равен null. В то время как в IE node.parentNode ссылается на DocumentFragment. Можно проверить таким кодом:
<div id="asd"></div>
<script>
node = document.body.removeChild(document.getElementById('asd'));
alert(node.parentNode && node.parentNode.nodeType);
</script>
Только в IE выдаст 11 (что соответствует DOCUMENT_FRAGMENT_NODE).
По этой причине, к примеру, нельзя проверить находится ли элемент в документе или нет (при условии что он может быть либо в документе, либо вне его - то есть при удалении из документа он не вложен в другой элемент) является неверным (точнее не работает в IE):
if (node.parentNode == null)
...
Если быть совсем точным, то parentNode равен null только после создания элемента (document.createElement), во всех остальных случаях он всегда ссылается на другие узлы (DocumentFragment тоже узел). Вот такой занятный DOM в исполнении IE :) Хотя может быть это разумно, кто знает?
0
Спасибо, очень полезное замечание, обязательно попробую. В нашем приложении такое добавление кучи фрагментов очень актуально. Я пользуюсь классом Template из Prototype'a: есть шаблон, туда подставляются нужные параметры и он вставляется в нужное место через innerHTML. Какие недостатки есть у такого подхода?
0
А где измерение времени работы вашего варианта кода, Николай? =)
0
Согласен с автором статьи. Использование DocumentFragment для вставки пачки элементов в дерево лучше даже не потому, что это работает быстрее. Это, если можно так выразиться, более логичный и естественный метод. Я DocumentFragment никогда не использовал просто в голову не приходило. Теперь попробую при первой же возможности.
Николай, предложенный тобой вариант с клонированием хорош, если только target для вставки фрагмента не содержит children. Иначе клонирование не применишь.
Николай, предложенный тобой вариант с клонированием хорош, если только target для вставки фрагмента не содержит children. Иначе клонирование не применишь.
0
он хорош (практически) во всех случаях. При наличии children мы также будем рекурсивно по ним пробегать во всех случаях. Издержки добавятся везде, а кеширование еще никто не отменял :)
0
Targets даже если содержат одинаковую структуру (тогда тоже клонирование работает, просто мы создаем объект для клонирования не пустой, а на основании одного из targets), то на элементах могут быть обработчики событий или некоторые из них могут иметь CSS-класс типа active (активный элемент, что часто бывает в последовательности одинаковых элементов) или selected/disabled/hidden. Иными словами, targets могут обладать какими-то индивидуальными свойствами, которые можно затереть клонированием.
Клонирование я бы использовал только тогда, когда я знаю конкретику targets (они одинаковые или когда я без труда смогу восстановить индивидуальные свойства targets после клонирования).
Клонирование я бы использовал только тогда, когда я знаю конкретику targets (они одинаковые или когда я без труда смогу восстановить индивидуальные свойства targets после клонирования).
0
Интересно, почему большинство веб-девелоперов очень редко пытаются понять суть явления? :)
Суть заключается в том, что когда вы вставляете ноды по одному сразу в нужное место в дереве документа, то браузеру нужно и css-правила перепроверить и layout переобсчитать и т.д. и т.п. и всё это ему сделать N раз. Когда же вы вставляете сразу фрагмент, то изменение дерева происходит один раз и, соответсвенно, пересчёт вроде как не относящихся к делу вещей происходит только один раз - отсюда и ускорение.
Суть заключается в том, что когда вы вставляете ноды по одному сразу в нужное место в дереве документа, то браузеру нужно и css-правила перепроверить и layout переобсчитать и т.д. и т.п. и всё это ему сделать N раз. Когда же вы вставляете сразу фрагмент, то изменение дерева происходит один раз и, соответсвенно, пересчёт вроде как не относящихся к делу вещей происходит только один раз - отсюда и ускорение.
+2
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Изменить настройки темы
DOM DocumentFragment: быстрее быстрого