Комментарии 10
по-моему у вас получился какой-то бред.
во первых, я смутно себе представляю ситуацию, когда нужно заполнить большое количество блоков одинаковыми dom-фрагментами. зачем такое может понадобиться?
во вторых, и ежу понятно, что производительнее сначала создать полный dom-фрагмент и затем клонировать его в каждый отдельный блок, чем каждый раз делать dom-фрагмент заново для каждого блока. изобретаете велосипеды?
каким местом сюда относится DocumentFragemnt совершенно не ясно...
во первых, я смутно себе представляю ситуацию, когда нужно заполнить большое количество блоков одинаковыми dom-фрагментами. зачем такое может понадобиться?
во вторых, и ежу понятно, что производительнее сначала создать полный dom-фрагмент и затем клонировать его в каждый отдельный блок, чем каждый раз делать dom-фрагмент заново для каждого блока. изобретаете велосипеды?
каким местом сюда относится DocumentFragemnt совершенно не ясно...
Если вы не сталкивались с такими задачами то это не значит что их нет. Одно заполнение карты маркерами чего стоит, когда на карту приходится загружать по несколько сотен или тысяч маркеров, и необходимо быстро модифицировать DOM дерево. А потом если сразу переключить на вывод вектора методами VML или SVG на тойже карте и убрать эти несколько сотен маркеров и показать к примеру маршруты общественного транспорта коих может быть также несколько сотен, или загрузить маплет который частично модифицирует интерфейс карт. Для юзера это должно работать быстро и прозрачно. Карты один из ярких примеров когда идет активная модификация DOM дерева, причем все должно работать без ошибок и быстро.
Кстати давно заметил такую интересную вещь. Когда делаешь
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 :) Хотя может быть это разумно, кто знает?
Спасибо, очень полезное замечание, обязательно попробую. В нашем приложении такое добавление кучи фрагментов очень актуально. Я пользуюсь классом Template из Prototype'a: есть шаблон, туда подставляются нужные параметры и он вставляется в нужное место через innerHTML. Какие недостатки есть у такого подхода?
А где измерение времени работы вашего варианта кода, Николай? =)
Согласен с автором статьи. Использование DocumentFragment для вставки пачки элементов в дерево лучше даже не потому, что это работает быстрее. Это, если можно так выразиться, более логичный и естественный метод. Я DocumentFragment никогда не использовал просто в голову не приходило. Теперь попробую при первой же возможности.
Николай, предложенный тобой вариант с клонированием хорош, если только target для вставки фрагмента не содержит children. Иначе клонирование не применишь.
Николай, предложенный тобой вариант с клонированием хорош, если только target для вставки фрагмента не содержит children. Иначе клонирование не применишь.
он хорош (практически) во всех случаях. При наличии children мы также будем рекурсивно по ним пробегать во всех случаях. Издержки добавятся везде, а кеширование еще никто не отменял :)
Targets даже если содержат одинаковую структуру (тогда тоже клонирование работает, просто мы создаем объект для клонирования не пустой, а на основании одного из targets), то на элементах могут быть обработчики событий или некоторые из них могут иметь CSS-класс типа active (активный элемент, что часто бывает в последовательности одинаковых элементов) или selected/disabled/hidden. Иными словами, targets могут обладать какими-то индивидуальными свойствами, которые можно затереть клонированием.
Клонирование я бы использовал только тогда, когда я знаю конкретику targets (они одинаковые или когда я без труда смогу восстановить индивидуальные свойства targets после клонирования).
Клонирование я бы использовал только тогда, когда я знаю конкретику targets (они одинаковые или когда я без труда смогу восстановить индивидуальные свойства targets после клонирования).
Интересно, почему большинство веб-девелоперов очень редко пытаются понять суть явления? :)
Суть заключается в том, что когда вы вставляете ноды по одному сразу в нужное место в дереве документа, то браузеру нужно и css-правила перепроверить и layout переобсчитать и т.д. и т.п. и всё это ему сделать N раз. Когда же вы вставляете сразу фрагмент, то изменение дерева происходит один раз и, соответсвенно, пересчёт вроде как не относящихся к делу вещей происходит только один раз - отсюда и ускорение.
Суть заключается в том, что когда вы вставляете ноды по одному сразу в нужное место в дереве документа, то браузеру нужно и css-правила перепроверить и layout переобсчитать и т.д. и т.п. и всё это ему сделать N раз. Когда же вы вставляете сразу фрагмент, то изменение дерева происходит один раз и, соответсвенно, пересчёт вроде как не относящихся к делу вещей происходит только один раз - отсюда и ускорение.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
DOM DocumentFragment: быстрее быстрого