it-swarm.com.ru

Почему концепция React Virtual DOM считается более производительной, чем грязная проверка моделей?

Я видел React выступление разработчика на http://www.youtube.com/watch?v=x7cQ3mrcKaY , и докладчик упомянул, что грязная проверка модели может быть медленной , Но не является ли вычисление различий между виртуальными DOM на самом деле еще менее производительным, поскольку виртуальная DOM в большинстве случаев должна быть больше, чем модель?

Мне действительно нравится потенциальная мощь Virtual DOM (особенно рендеринг на стороне сервера), но я хотел бы знать все плюсы и минусы.

344
Daniil

Я являюсь основным автором модуля virtual-dom , поэтому я могу ответить на ваши вопросы. На самом деле есть 2 проблемы, которые необходимо решить здесь

  1. Когда я перерисовываю? Ответ: Когда я вижу, что данные грязные.
  2. Как эффективно выполнить рендеринг? Ответ: Использование виртуального DOM для создания реального патча DOM

В React каждый из ваших компонентов имеет состояние. Это состояние похоже на наблюдаемое, которое вы можете найти в нокауте или других библиотеках стилей MVVM. По сути, React знает , когда повторно визуализировать сцену, потому что она может наблюдать, когда эти данные изменяются. Грязная проверка выполняется медленнее, чем наблюдаемые, поскольку необходимо регулярно опрашивать данные и рекурсивно проверять все значения в структуре данных. Для сравнения, установка значения для состояния будет сигнализировать слушателю, что какое-то состояние изменилось, поэтому React может просто прослушивать события изменения состояния и ставить в очередь повторный рендеринг.

Виртуальный DOM используется для эффективного повторного рендеринга DOM. Это на самом деле не связано с грязной проверкой ваших данных. Вы можете выполнить рендеринг с использованием виртуального DOM с грязной проверкой или без нее. Вы правы в том, что при вычислении различий между двумя виртуальными деревьями возникают некоторые накладные расходы, но виртуальная разность DOM заключается в понимании того, что необходимо обновить в DOM, а не в том, изменились ли ваши данные. Фактически, алгоритм diff сам по себе является грязной проверкой , но он используется, чтобы увидеть, не является ли DOM грязным.

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

Виртуальный DOM хорош, потому что он позволяет нам писать наш код так, как будто мы перерисовываем всю сцену. За кулисами мы хотим вычислить операцию исправления, которая обновляет DOM, чтобы посмотреть, как мы ожидаем. Таким образом, хотя алгоритм DOM diff/patch виртуального DOM , вероятно, не является оптимальным решением , он дает нам очень хороший способ выразить наши приложения. Мы просто объявляем, чего именно хотим, и React/virtual-dom решит, как сделать вашу сцену такой. Нам не нужно вручную манипулировать DOM или запутаться в предыдущем состоянии DOM. Нам также не нужно перерисовывать всю сцену, что может быть гораздо менее эффективно, чем ее исправление.

470
Matt Esch

Недавно я прочитал подробную статью об алгоритме сравнения React здесь: http://calendar.perfplanet.com/2013/diff/ . Насколько я понимаю, React быстро делает следующее:

  • Пакетные операции чтения/записи DOM.
  • Эффективное обновление только поддерева.

По сравнению с грязной проверкой ключевые отличия IMO:

  1. Проверка загрязненности модели : React компонент явно устанавливается как загрязненный при каждом вызове setState, поэтому нет сравнения (данных) нужен здесь. Для грязной проверки сравнение (моделей) всегда происходит в каждом цикле дайджеста.

  2. Обновление DOM : операции DOM очень дороги, потому что модификация DOM также будет применяться и вычислять стили CSS, макеты. Сэкономленное время от ненужной модификации DOM может быть больше, чем время, потраченное на распространение виртуальной DOM.

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

128
tungd

Мне действительно нравится потенциальная мощь Virtual DOM (особенно рендеринг на стороне сервера), но я хотел бы знать все плюсы и минусы.

- OP

React - не единственная библиотека манипулирования DOM. Я рекомендую вам понять альтернативы, прочитав это статья от Auth , которая включает подробное объяснение и тесты. Я выделю здесь их плюсы и минусы, как вы спросили:

Виртуальный DOM React.js

enter image description here

ПРОФИ

  • Быстрый и эффективный "дифференцирующий" алгоритм
  • Несколько интерфейсов (JSX, гиперскрипт)
  • Достаточно легкий, чтобы работать на мобильных устройствах
  • Много тяги и ума
  • Может использоваться без React (т.е. как независимый движок)

МИНУСЫ

  • Полная копия DOM в памяти (более интенсивное использование памяти)
  • Нет различия между статическими и динамическими элементами

Ember.js 'Glimmer

enter image description here

ПРОФИ

  • Быстрый и эффективный алгоритм сравнения
  • Различие между статическими и динамическими элементами
  • 100% совместимость с API Ember (вы получаете преимущества без значительных обновлений существующего кода)
  • Облегченное представление DOM в памяти

МИНУСЫ

  • Предназначено для использования только в Ember
  • Доступен только один интерфейс

Инкрементальный DOM

enter image description here

ПРОФИ

  • Уменьшенное использование памяти
  • Простой API
  • Легко интегрируется со многими интерфейсами и фреймворками (изначально задумывался как бэкэнд механизма шаблонов)

МИНУСЫ

  • Не так быстро, как другие библиотеки (это спорно, см тестов ниже)
  • Меньше разума и использования сообщества
72
falsarella

Вот комментарий React члена команды Себастьяна Маркбога, который проливает некоторый свет:

React выполняет анализ выходных данных (это известный сериализуемый формат, атрибуты DOM). Это означает, что исходные данные могут быть любого формата. Это могут быть неизменяемые структуры данных и состояния внутри замыканий.

Модель Angular не сохраняет ссылочную прозрачность и поэтому является изменчивой по своей природе. Вы изменяете существующую модель, чтобы отслеживать изменения. Что если ваш источник данных - это неизменяемые данные или новая структура данных каждый раз (например, ответ JSON)?

Грязная проверка и Object.observe не работают с состоянием области закрытия.

Эти две вещи очень ограничивают функциональные паттерны.

Кроме того, когда сложность вашей модели возрастает, делать грязное отслеживание становится все дороже. Однако, если вы выполняете только диффузию по визуальному дереву, например, React, оно не увеличивается так сильно, поскольку объем данных, которые вы можете отобразить на экране в любой заданной точке, ограничен пользовательским интерфейсом. Приведенная выше ссылка Пита охватывает больше преимуществ.

https://news.ycombinator.com/item?id=6937668

36
Sophie Alpert

Вы можете прочитать это ( https://reactkungfu.com/2015/10/the-difference-between-virtual-dom-and-dom/ ) искусно узнать о Real DOM и Virtual DOM. Надеюсь, это поможет вам!

0
Hardik Chaudhary