В мире существует множество игровых движков: Unreal Engine, Unity Engine, Godot Engine, Cry Engine и другие.

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

Теперь вернемся к фронтенд-разработке. React — один из самых популярных фреймворков в этой области. Но так же, как модификация движка является обычным явлением в разработке игр, так же распространено ли изменение внутреннего исходного кода React при разработке внешнего интерфейса? Этот простой вопрос многое говорит о том, чем мы на самом деле преследуем, и подчеркивает разницу в направлении современной фронтенд-разработки и других областей.

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

"Бесплатных обедов не бывает."
«Не существует инструмента, который мог бы сделать все».

React — это всего лишь один из инструментов разработки, и у него есть свои ограничения.

Основная причина, по которой разработчики используют React, — это производительность. React был создан с вопросом: «Как мы можем более эффективно разрабатывать компоненты DOM в веб-разработке?» В центре подхода React находится DOM. Точно так же, как автоматизированные функции обычно означают отсутствие настройки, «производительность», о которой они говорят, часто означает, что «вы не можете изменить цикл рендеринга, тесно связанный с браузером, через виртуальный DOM».

Первая серьезная проблема React — это DOM. Не все вращается вокруг DOM, и не каждая программа работает исключительно вокруг него. Тем не менее, React ставит DOM в основу своей философии. Синтаксис JSX, где каждый компонент возвращает что-то «подобное HTML-элементу», ясно отражает этот образ мышления.

Вторая проблема — виртуальный DOM. Вот как работает виртуальный DOM:

• DOM по своей сути медленный.
• Чтобы смягчить эту проблему, React вводит более быструю внутреннюю логику.
• Эта логика создает объект, который копирует форму фактического дерева DOM, известного как виртуальный DOM. Всякий раз, когда происходит рендеринг, React находит изменения, используя этот виртуальный DOM, и обновляет только эти части.
• Для реализации этой системы обновления DOM всегда должны проходить через корневой элемент DOM.
• Виртуальный DOM прекрасно работает с внутренними операциями React.

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

В HPSE компонентами DOM можно управлять на уровне класса. При создании экземпляра его ссылка на DOM div верхнего уровня сохраняется как переменная-член. Частные методы экземпляра могут либо напрямую манипулировать ссылкой на DOM, либо использовать querySelector() для доступа к ней. В большинстве случаев это будет быстрее, чем сравнение всего дерева DOM.

Использование виртуального DOM — это всего лишь способ идентифицировать изменения, но если у вас уже есть изменения, хранящиеся внутри вашего экземпляра, их повторный поиск является излишним. После обновления элемента DOM браузер по-прежнему будет запускать ReFlow и RePaint, поэтому впоследствии разницы в производительности не будет.

Основная проблема заключается во «внутренних операциях» React. Что именно представляют собой эти внутренние операции? Не хватает подробной документации или информации, и большинство разработчиков интерфейса также не до конца их понимают. Клиент браузера уже работает на уровне абстракции самого браузера, что делает его уязвимым для различных проблем. Непрозрачные и неизменяемые внутренние процессы React только усугубляют эту уязвимость.

Изменения компонентов в React должны проходить через виртуальный DOM, а виртуальный DOM управляется архитектурой Fiber, которая следует определенным правилам приоритета. Однако существует мало документации о том, как настроить внутренние функции React для удовлетворения требований HPSE к производительности в реальном времени или точности синхронизации. Это похоже на разработку ААА-игры на движке, который невозможно настроить.

"Зачем беспокоиться?"

Этот вопрос постоянно возникает.

React настолько тесно связан внутри, что даже если бы вы захотели его изменить, вы не смогли бы это сделать. Он никогда не создавался с этой целью. Более того, сильная связь рендеринга и обновления состояния делает React непригодным для проектов HPSE, где невизуальные компоненты, такие как данные или 3D-элементы, должны управляться вместе с элементами DOM.

В HPSE время вызовов событий и размонтирования памяти не может быть привязано к отдельным компонентам, но React применяет эту структуру на основе компонентов, что затрудняет обработку таких требований. Дизайн React, в котором изменения состояния компонентов могут повлиять на все дерево рендеринга, также противоречит необходимости HPSE минимизировать или контролировать такие воздействия.

Библиотеки, такие как React Three Fiber (R3F), позволяют создавать такие экземпляры, как Mesh или Scene, используя синтаксис «HTML Element Like», но это просто Three.js, адаптированный к структуре React. Высокий уровень связанности внутри React только усугубляет проблему неизменяемости внутренних компонентов.

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

Эти проблемы возникают потому, что философия дизайна React фундаментально отличается от целей HPSE. React не был создан с учетом HPSE; он был разработан для оптимизации разработки стандартных веб-клиентов. Если бы React действовал в том же направлении, что и HPSE, его функции были бы совершенно другими, и было бы целесообразно использовать его при разработке HPSE. Но поскольку их цели настолько различаются, их пути неизбежно расходятся.

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