Команда разработчиков Mindsapp смогла перейти от "перегруженного виртуального DOM" React к современным DOM API. Они сразу заметили увеличение скорости и улучшение работы интерактивных элементов. Время загрузки страницы с данными сократилось с 6 сек до 300 мс.
Для разработки пользовательского интерфейса своего веб-браузера Edge, Microsoft недавно начала отходить от React и других JavaScript-фреймворков в пользу "HTML-first" - подхода, который больше "ориентирован на верстку, использование небольших пакетов и меньшее количество JavaScript-кода для рендеринга UI".
С 6 сек до 300 мс
Жюльен Мулис (Julien Moulis), старший фронтенд-разработчик швейцарской IT-компании Eukleia, которая сейчас работает над инструментом для разработчиков под названием Mindsapp, рассказал, что его команда "решила сменить React со всеми его сложностями виртуального DOM на прекрасное современное DOM API".
"Несколько месяцев назад мы решили перевести часть нашего приложения с React на чистый JavaScript." – Julien Moulis, Mindsapp
"Я не мог понять, как именно обновления текста, анализ виртуального DOM и всех конкурентных процессов и сотен функций может быть быстрее, чем просто обновление самого элемента DOM. Поэтому я создал небольшое SSR-приложение на Node.js для хранения данных и маршрутизации. Также я использовал RxJS для фронтенд-компонентов веб-приложения - и мы смогли сократить время загрузки на некоторых страницах с большим объемом данных с 6 секунд до 300 мс."
Как он это сделал?
Жюльен описал приложение Mindsapp, как "приложение с низким уровнем кодирования, чтобы мы могли разрабатывать приложения быстрее - это приложение, созданное разработчиками для разработчиков."
Главная цель Mindsapp - помогать разработчикам ускорять свое развитие, команда была обеспокоена тем, что React на самом деле замедляет его.
Проблемы с React
"Мы почувствовали, что наши потребности уже не совпадают с парадигмой React."
Одна из особенностей Mindsapp - создание веб-страниц, которые представляют собой графовую сеть. Она построена с использованием Neo4j. Мулис объяснил, как работала версия на React с использованием страниц:
"Когда я запрашиваю форму, то получаю объект, который содержит, среди прочего, массив элементов: [...] До сих пор, когда я получал эти элементы, то передавал их через рекурсивную функцию. Она создавала различные компоненты React на основе карты, индексированной по свойству 'компонент'. После отображения пользователь получал доступ ко всем базовым интерактивным элементам формы, навигации и т. д."
Они также использовали API контекста и редьюсеры React для "управления всеми данными и обновлениями", а для маршрутизации использовали React-router. React Редьюсеры - это функции, которые принимают текущее состояние и действие (action) в качестве аргументов и возвращают новое состояние.
У этого подхода на основе React было несколько ключевых проблем:
- Ненужные ререндеры, даже несмотря на значительные усилия по оптимизации с использованием имеющихся хуков.
- Маршрутизация. "Поскольку страницы представляли собой объекты, возвращаемые бэкендом", - сказал Мулис, - "мы не могли заранее определить все маршруты".
После переосмысления этих проблем Мулис задал себе вопрос: "Как изменение значения простого ввода и отображение простого элемента span с введенным текстом может быть быстрее через фреймворк, чем прямое обращение к этому элементу?'"
Это стало триггером для поиска решения, которое было бы ближе к принципам работы браузера.
Реализация подхода с использованием нативного API DOM.
После различных попыток изменить структуру их приложения, Мулис и его команда в конечном итоге решили приблизиться к нативным API DOM.
"Мы были полностью удивлены увеличением скорости."
«Для этого мы настроили простой сервер SSR (Node), чтобы предварительно отображать наши объекты бэкэнда и создавать наши компоненты с помощью простого парсера строк шаблона и карты», - сказал он.
Вот обзор того, что сделала команда Mindsapp:
«Для достижения этой цели наш компонент Link отправляет запросы напрямую на SSR-сервер Если ответ положительный, сервер SSR возвращает страницу; если произошла ошибка, он отправляет страницу с кодом 500 или 404. Мы также настроили простой RxJS fromEvent непосредственно на объекте window для обработки нативной навигации браузера, который также отправляет запросы на SSR-сервер».
Им потребовался месяц для реализации этого, но результаты сразу же стали заметны.
«Наш движок приложения разработан для создания сложных приложений типа ERP, которые требуют интенсивного потребления данных для представления в реальном времени. На странице, которую мы считаем сложной, с более чем 800 элементами DOM, некоторые из которых используют различные системы подписки через нашу систему событий при инициализации для обновления при необходимости, общее время загрузки сократилось с 4–5 секунд до 400 мс».
"В плане взаимодействия больше нет бесконечной проверки, чтобы убедиться, что дочерний компонент не обновляется, даже если обновляется состояние компонента-родителя".
Увеличение скорости положительное сказалось на взаимодействие с пользователями.
"В плане взаимодействия больше нет бесконечной проверки, чтобы убедиться, что дочерний компонент не обновляется, даже если обновляется состояние родителя. Простой и банальный пример: пользователь может захотеть изменить цвет фона карточки по клику, содержащей в себе граф. Мы можем сделать это, не беспокоясь о том, обновится граф или нет".
Недостатки
Мулис, однако, признал, что подход, основанный на HTML, имеет свои недостатки. Он описывает веб-компоненты как "очень многословные" и отмечает, что "мы несем ответственность за то, чтобы гарантировать, что все подписки, сделанные элементами, правильно очищаются при уничтожении элементов".
Он добавил, что поиск разработчиков, знакомых не только с фреймворками, но и с "ванильным" JavaScript, был неожиданной сложностью.
"Тем не менее", - сказал он, - "преимущества такого подхода для пользователей очевидны. Улучшение пользовательского опыта всегда было нашим приоритетом".
Статья переведена из источника: https://thenewstack.io/pivoting-from-react-to-native-dom-apis-a-real-world-example