Я побачив розмову про реагентів ( Pete Hunt: React: Переосмислення найкращих практик - JSConf EU 2013 ) і спікер зазначив, що брудна перевірка моделі може бути повільною. Але чи не обчислення різниці між віртуальними DOM насправді навіть менш ефективно, оскільки віртуальна DOM у більшості випадків повинна бути більшою, ніж модель?

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

Я основний автор модуля віртуального дому , тому я можу відповісти на ваші запитання. Насправді є дві проблеми, які тут потрібно вирішити

1. Коли я повторно візуалізую? Відповідь: Коли я помічаю, що дані брудні.
2. Як я можу ефективно відреагувати? Відповідь: Використання віртуального DOM для генерації реального патчу DOM

У React кожен ваш компонент має стан. Цей стан схожий на спостереження, яке ви можете знайти в нокауті або інших бібліотеках стилів MVVM. По суті, React знає, коли потрібно відредагувати сцену, оскільки він може спостерігати, коли ці дані змінюються. Брудна перевірка відбувається повільніше, ніж спостерігається, оскільки ви повинні регулярно опитувати дані та рекурсивно перевіряти всі значення в структурі даних. Для порівняння, встановлення значення стану сигналізуватиме слухачеві про те, що деякий стан змінився, тому React може просто прослухати події зміни у стані та встановити чергу до повторного відтворення.

Віртуальний DOM використовується для ефективного відтворення DOM. Це насправді не пов’язано з брудною перевіркою даних. Ви можете повторно відтворити, використовуючи віртуальний DOM з брудною перевіркою або без неї. Ви маєте рацію в тому, що в обчисленні різниці між двома віртуальними деревами існує деяка накладні витрати, але віртуальна DOM-різниця полягає в розумінні того, що потребує оновлення в DOM, а не в тому, змінилися чи не ваші дані. Насправді алгоритм diff - це сама брудна перевірка, але вона використовується, щоб перевірити, чи замість цього DOM брудний.

Ми прагнемо відновити віртуальне дерево лише тоді, коли стан зміниться. Тож використання спостережуваної для перевірки, чи змінився стан, є ефективним способом запобігання непотрібних повторних проявів, що може спричинити багато непотрібних дерев. Якщо нічого не змінилося, ми нічого не робимо.

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

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

• Пакетні операції з читання / запису DOM.
• Ефективне оновлення лише піддерева.

У порівнянні з методом брудної перевірки, ключовими відмінностями ІМО є:

1. Брудна перевірка моделі : компонент React явно встановлюється як брудний при кожному setStateвиклику, тому тут немає необхідного порівняння (даних). Для брудної перевірки порівняння (у моделях) завжди відбувається у кожному циклі дайджесту.

2. Оновлення DOM : Операції з DOM дуже дорогі, оскільки зміна DOM також застосовуватиметься та обчислюватиме стилі, макети CSS. Заощаджений час від непотрібних модифікацій DOM може бути довшим, ніж витрачений час, що відрізняється від віртуальної DOM.

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

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

- ОП

React - не єдина бібліотека маніпуляцій DOM. Я закликаю вас зрозуміти альтернативи, прочитавши цю статтю від Auth0, яка включає детальне пояснення та орієнтири. Тут я виділю їх плюси та мінуси, як ви запитали:

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

ПРОС

• Швидкий та ефективний алгоритм "відрізняється"
• Кілька фронтальних (JSX, гіперскрипт)
• Досить легкий для роботи на мобільних пристроях
• Багато тяги та розуму
• Можна використовувати без React (тобто як незалежний двигун)

КОНС

• Повна копія DOM в пам'яті (вищий обсяг пам’яті)
• Немає диференціації між статичними та динамічними елементами

---

Elim.js 'Glimmer

ПРОС

• Швидкий та ефективний алгоритм, що відрізняється
• Диференціація між статичними та динамічними елементами
• На 100% сумісний з API Ember (ви отримуєте переваги без великих оновлень існуючого коду)
• Легке представлення DOM в пам'яті

КОНС

• Мається на увазі, що використовується тільки в Ембер
• Доступний лише один фронтенд

---

Поступовий ДОМ

ПРОС

• Скорочення використання пам'яті
• Простий API
• Легко інтегрується з багатьма фронтальними і фреймовими рамками (мається на увазі як шаблон двигуна шаблону від початку)

КОНС

• Не так швидко, як інші бібліотеки (це сперечається, див. Орієнтири нижче)
• Менше використання розуму та використання громади

Ось коментар члена команди Реакти Себастьяна Маркбоге, який проливає трохи світла:

React робить різний на виході (який відомий серіалізаційний формат, атрибути DOM). Це означає, що вихідні дані можуть мати будь-який формат. Це можуть бути незмінні структури даних та стан всередині закритих блоків.

Кутова модель не зберігає еталонної прозорості і тому є по своїй суті змінюваною. Ви мутуєте існуючу модель для відстеження змін. Що робити, якщо у вашому джерелі даних кожен раз є незмінні дані або нова структура даних (наприклад, відповідь JSON)?

Брудна перевірка та Object.observe не працює у стані області закриття.

Ці дві речі очевидно дуже обмежують функціональні зразки.

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

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

Віртуальний дім не винайдений реагуванням. Він є частиною HTML dom. Він легкий і відокремлений від деталей, що стосуються браузера.

Ми можемо вважати віртуальний DOM локальною та спрощеною копією HTML DOM. Це дозволяє React робити свої обчислення в цьому абстрактному світі та пропускати "справжні" DOM-операції, часто повільні та залежні від браузера. Насправді немає великої різниці між DOM та VIRTUAL DOM.

Нижче наведено моменти, чому використовується Virtual Dom (джерело Virtual DOM в ReactJS ):

Коли ви робите:

document.getElementById('elementId').innerHTML = "New Value" Following thing happens:

1. Браузер повинен проаналізувати HTML
2. Він видаляє дочірній елемент elementId
3. Оновить значення DOM на нове значення
4. Перерахуйте повторно css для батька та дитини
5. Оновіть макет, тобто для кожного елемента точні координати на екрані
6. Обведіть дерево візуалізації та намалюйте його на дисплеї браузера

Перерахунок CSS та змінених макетів використовує складний алгоритм, який впливає на продуктивність.

А також оновлення властивостей DOM, тобто. значення. Це слідує алгоритму.

Припустимо, якщо ви оновите DOM 10 разів безпосередньо, то всі вищезазначені кроки виконуватимуться один за одним, і для оновлення DOM-алгоритмів знадобиться час для оновлення значень DOM.

Ось чому Real DOM повільніше, ніж віртуальний DOM.