Многократная маленькая операция DOM против одной большой операции DOM - PullRequest
4 голосов
/ 06 января 2012

Это больше вопрос о лучших практиках.Пытаясь применить MVC-подобный шаблон проектирования в веб-приложении, я часто задаюсь вопросом, как мне поступить с обновлением View.

Например, если мне нужно обновить View_1, у которого есть X элементов.Лучше ли:

A: перебрать каждый из элементов X, выяснить, какие из них необходимо обновить, и применить изменение DOM с очень высокой степенью детализации.

или

B: использование данных, предоставленных Model или какой-либо другой структурой данных, для регенерации разметки для всего этого View и всех его элементов, а также для замены корневого элемента View_1 за одну манипуляцию DOM?

Исправьте меняесли я ошибаюсь.Я слышал, что механизмы рендеринга обычно более эффективны при замене большого количества DOM за один раз, чем несколько меньших операций DOM.Если это так, то подход B является лучшим.Однако даже при использовании шаблонизаторов мне все еще иногда трудно избежать переписывания пометок для тех частей представления, которые не были изменены.

Я изучил исходный код проекта Bespin до того, как переименовал его.Я отчетливо помню, что они реализовали своего рода механизм цикла рендеринга, в котором DOM-операции ставятся в очередь и применяются через фиксированные промежутки времени, во многом подобно тому, как игры управляют своими кадрами.Это похоже на подход А. Я также вижу причины этого подхода.Небольшие операции DOM, применяемые таким образом, поддерживают отзывчивость пользовательского интерфейса (особенно важно для веб-текстового редактора).Также таким образом, приложение может быть сделано более эффективным, только обновляя элементы, которые должны быть изменены.Статический текст и эстетические элементы могут остаться нетронутыми.

Это мои аргументы в пользу обеих сторон.Что, вы парни, думаете?Ищем ли мы где-нибудь счастливую среду, или один подход в целом превосходит?

Кроме того, есть ли хорошие книги / статьи / сайты по этой конкретной теме?

(давайте предположим, чторассматриваемое веб-приложение сильно загружено многими динамическими обновлениями)

Ответы [ 2 ]

2 голосов
/ 06 января 2012

Это правда, что движки рендеринга обычно обрабатывают изменения в больших чанках быстрее, чем множественные небольшие изменения.

tl; dr: идеал беспилотный, и если вы можете, сделайте это на рабочем месте.

В зависимости от размера количества изменений, вы можете попытаться запустить работника и выполнить расчет изменений внутри работника, так как JS долго блокировал пользовательский интерфейс. Вы можете рассмотреть возможность использования следующего потока:

  1. Создать объект с частью дерева dom, а также с родительским идентификатором.
  2. Stringify объект в JSON
  3. Начать рабочий
  4. Передача строкового объекта в рабочий
  5. Получить и разобрать строку.
  6. Работайте над изменением всех необходимых частей дерева дерева, в которое вы прошли.
  7. Снова строчить объект.
  8. Передайте объект обратно в главный поток.
  9. Разобрать и извлечь новое дерево dom.
  10. Вставьте в дом снова.

Это будет быстрее, если будет много изменений и небольшое дерево. Если это большое дерево и мало изменений, то выполнение локальных изменений в копии реального дерева DOM будет быстрее, а затем обновление DOM за один раз.

Также читайте сайты Google о скорости страницы:

https://code.google.com/speed/articles/

И особенно эта статья:

https://code.google.com/speed/articles/javascript-dom.html

0 голосов
/ 18 ноября 2015

После 3 лет работы с различными веб-технологиями, я думаю, я наконец-то нашел отличный баланс между двумя подходами: виртуальный DOM

Библиотеки, такие как vdom, Elm, mithril.js и в некоторой степени Facebook Reactотслеживает тонкую абстракцию фактического DOM, выясняет, что необходимо изменить, и пытается применить наименьшее возможное изменение DOM.

например

https://github.com/Matt-Esch/virtual-dom/tree/master/vdom

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...