Existem muitos motores de jogo no mundo: Unreal Engine, Unity Engine, Godot Engine, Cry Engine e muito mais.

O que esses motores de jogo têm em comum? Personalização. Jogos diferentes têm requisitos diferentes e precisam de recursos específicos para atingir seus objetivos. É difícil fornecer todos os recursos possíveis em um único programa, e é por isso que muitos mecanismos permitem que os desenvolvedores modifiquem o código-fonte e criem seus próprios recursos personalizados. A personalização é uma parte essencial desses motores.

Agora, vamos voltar ao desenvolvimento front-end. React é um dos frameworks mais populares neste espaço. Mas, assim como modificar o mecanismo é comum no desenvolvimento de jogos, é tão comum modificar o código-fonte interno do React no desenvolvimento frontend? Esta pergunta simples revela muito sobre o que realmente buscamos e destaca a diferença de direção entre o desenvolvimento de front-end moderno e outros campos.

React é uma estrutura quase impossível de modificar. Recomendamos que você use o React como está e não se destina aos desenvolvedores personalizarem sua arquitetura interna ou pipeline de renderização. Portanto, usar o React significa que você deve resolver todos os seus requisitos dentro dos limites da estrutura do React. Mas o mundo está cheio de diversos requisitos e nem todos eles podem ser resolvidos dentro da estrutura do React.

"Não existe almoço grátis."
"Não existe ferramenta que possa fazer tudo."

React é apenas uma ferramenta de desenvolvimento e tem seus limites.

O principal motivo pelo qual os desenvolvedores usam o React é a produtividade. O React foi criado com a pergunta: “Como podemos desenvolver componentes DOM de forma mais eficiente no desenvolvimento web?” No centro da abordagem do React está o DOM. Assim como os recursos automatizados geralmente significam falta de personalização, a "produtividade" de que falam geralmente significa "você não pode modificar o loop de renderização fortemente acoplado ao navegador por meio do DOM virtual".

O primeiro grande problema do React é o DOM. Nem tudo gira em torno do DOM e nem todo programa opera exclusivamente em torno dele. Ainda assim, o React coloca o DOM no centro de sua filosofia. A sintaxe JSX, onde cada componente retorna algo "semelhante a um elemento HTML", reflete claramente essa mentalidade.

A segunda questão é o DOM virtual. Veja como funciona o DOM virtual:

O DOM é inerentemente lento.
Para mitigar isso, o React introduz uma lógica interna mais rápida.
Essa lógica cria um objeto que copia a forma da árvore DOM real, conhecida como DOM virtual. Sempre que ocorre a renderização, o React encontra as alterações usando este DOM virtual e atualiza apenas essas partes.
Para implementar este sistema, as atualizações do DOM devem sempre passar pelo elemento raiz do DOM.
O virtual O DOM funciona perfeitamente com as operações internas do React.

A questão é: por que a HPSE adotaria tal sistema em primeiro lugar? Além da preocupação de que esta abordagem de renderização não possa atender a vários requisitos do HPSE, a maior preocupação é a falta de utilidade real neste contexto.

No HPSE, os componentes DOM podem ser gerenciados no nível da classe. Quando uma instância é criada, sua referência DOM div de nível superior é armazenada como uma variável de membro. Os métodos privados da instância podem manipular diretamente a referência DOM ou usar querySelector() para acessá-la. Na maioria dos casos, isso seria mais rápido do que comparar toda a árvore DOM.

Usar o DOM virtual é apenas uma forma de identificar alterações, mas se você já tem as alterações armazenadas internamente em sua instância, procurá-las novamente é redundante. Depois que o elemento DOM for atualizado, o navegador ainda acionará ReFlow e RePaint, portanto, não haverá diferença no desempenho posteriormente.

O problema final está nas "operações internas" do React. O que exatamente são essas operações internas? Falta documentação ou informações detalhadas, e a maioria dos desenvolvedores front-end também não as entende completamente. O cliente do navegador já opera dentro da camada de abstração do próprio navegador, tornando-o vulnerável a diversos desafios. Os processos internos opacos e não modificáveis ​​do React apenas agravam esta vulnerabilidade.

As alterações nos componentes do React devem passar pelo DOM virtual, e o DOM virtual é gerenciado pela arquitetura Fiber, que segue regras de prioridade específicas. No entanto, há pouca documentação sobre como personalizar as funções internas do React para atender ao desempenho em tempo real ou às demandas de tempo preciso do HPSE. É como desenvolver um jogo AAA com um motor que não pode ser personalizado.

"Por que se preocupar?"

É uma pergunta que sempre surge.

O React é tão intimamente acoplado internamente que, mesmo que você quisesse modificá-lo, não conseguiria. Nunca foi projetado com esse propósito em mente. Além disso, o forte acoplamento de renderização e atualizações de estado torna o React inadequado para projetos HPSE, onde componentes não visuais, como dados ou elementos 3D, devem ser gerenciados juntamente com elementos DOM.

No HPSE, o tempo de chamadas de eventos e desmontagens de memória pode não estar vinculado a componentes individuais, mas o React impõe essa estrutura baseada em componentes, tornando difícil lidar com tais requisitos. O design do React, onde mudanças de estado nos componentes podem afetar toda a árvore de renderização, também entra em conflito com a necessidade do HPSE de minimizar ou controlar tais impactos.

Bibliotecas como React Three Fiber (R3F) permitem que você crie instâncias como Mesh ou Scene usando uma sintaxe "HTML Element Like", mas isso é simplesmente Three.js adaptado à estrutura do React. O alto nível de acoplamento no React apenas piora o problema de componentes internos não modificáveis.

A abordagem de tratamento de eventos do React também é problemática. O React usa um sistema de eventos sintético para garantir a compatibilidade do navegador e a consistência no tratamento de eventos. No entanto, ao adicionar uma camada de abstração ao processamento de eventos, este sistema limita o controle refinado sobre os loops de eventos e o tempo necessário no HPSE, dificultando a implementação de otimizações essenciais.

Esses problemas surgem porque a filosofia de design do React é fundamentalmente diferente dos objetivos do HPSE. O React não foi desenvolvido com o HPSE em mente; ele foi projetado para otimizar o desenvolvimento de clientes web padrão. Se o React tivesse seguido uma direção semelhante ao HPSE, seus recursos teriam sido muito diferentes e haveria motivos para adotá-lo no desenvolvimento do HPSE. Mas como seus objetivos são tão divergentes, eles inevitavelmente se separam.

Isso não quer dizer que tudo sobre React, como roteamento ou useEffect, seja ruim. Na verdade, a maioria desses recursos pode ser implementada usando módulos ou códigos JavaScript independentes. Ao contrário do React, os módulos JavaScript gerais não impõem pipelines ou regras específicas aos projetos. Além disso, se eles forem de código aberto, você poderá modificar seus componentes internos para atender às suas necessidades.