Pivotando de React para APIs DOM nativas: um exemplo do mundo real

Para desenvolver a interface do usuário de seu navegador Edge, a Microsoft recentemente começou a se afastar do React e de outras estruturas JavaScript para adotar o que chamou de abordagem “HTML-first”. Em vez de usar o React para criar a interface do usuário – o paradigma de desenvolvimento web mais comum atualmente – a equipe do Microsoft Edge adotou uma abordagem descrita como “primeiro marcação, pacotes pequenos e menos código JavaScript de renderização de interface do usuário”.

Depois de publicarmos esse post, fui abordado por um desenvolvedor que também havia feito uma transição semelhante. Julien Moulis é desenvolvedor front-end sênior em uma empresa suíça de TI chamada Eukleia, que está construindo uma ferramenta de desenvolvedor personalizada chamada Mindsapp. Moulis entrou em contato para me dizer que, para Mindsapp, sua equipe “decidiu fazer a mudança do esmagador VDOM do React para a fantástica e moderna API DOM”.

“Há alguns meses, decidimos fazer a transição de uma parte de nosso aplicativo do React para o vanilla JavaScript.”
– Julien Moulis, Mindsapp

Veremos o que isso significa em breve, mas primeiro quero citar Moulis sobre o que mudou e o impacto que isso teve nos usuários finais. (E observe que, como Moulis não é falante nativo de inglês, editei levemente suas citações para maior clareza no idioma.)

“Não consegui entender como, por apenas atualizar o texto, analisar um VDOM e todas as concorrências e centenas de funções, poderia ser mais rápido do que apenas atualizar o próprio elemento DOM. Então construí um pequeno SSR Node.js, para dados reativos e roteamento, RxJS para os componentes web frontend — e reduzimos o tempo de carregamento em algumas páginas com muitos dados, de 6 segundos para 300 ms.”

Para resumir, Moulis simplificou seu aplicativo passando de uma estrutura virtual complexa baseada em DOM (React) para uma abordagem mais simples e direta usando tecnologias web modernas, resultando em tempos de carregamento muito mais rápidos para os usuários.

Então, como ele fez isso? Pedi a Moulis que me contasse a história.

“Há alguns meses, decidimos fazer a transição de uma parte de nosso aplicativo do React para o vanilla JavaScript”, ele me disse. Ele descreveu o aplicativo de sua empresa, Mindsapp, como “um aplicativo de baixo código que nos permite desenvolver aplicativos com mais rapidez – é um aplicativo feito por desenvolvedores para desenvolvedores”.

Como o objetivo do Mindsapp é ajudar os desenvolvedores a acelerar seu desenvolvimento, a equipe estava preocupada que o React estivesse realmente desacelerando o desenvolvimento.

Os problemas com reação no Mindsapp

“Acontece que sentimos que nossas necessidades não estão mais alinhadas com o paradigma React.”

Uma das funcionalidades do Mindsapp é um criador de páginas, onde as páginas são uma rede gráfica construída com Neo4j. Moulis explicou como funcionou a versão React usando páginas:

“Quando solicito um formulário, recebo um objeto que contém, entre outras coisas, um array de elementos. (…) Até agora, quando recebi estes elementos, passei-os através de uma função recursiva que construía os vários componentes do React com base num Mapa indexado pela propriedade ‘component’. Uma vez renderizado, o usuário tinha acesso a todas as interações básicas do formulário, navegação, etc.”

Eles também usaram a API de contexto e redutores do React “para gerenciar todos os dados e atualizações” e para roteamento usaram o roteador React.

Houve alguns problemas importantes com essa abordagem do React. A primeira foram “renderizações desnecessárias” – mesmo que eles tivessem feito “esforços significativos para otimizar usando os ganchos disponíveis”. O segundo foram problemas com roteamento. “Como as páginas eram objetos retornados pelo backend”, disse Moulis, “não pudemos definir todas as rotas com antecedência”.

Depois de pensar nos problemas, Moulis se perguntou: “Como modificar um valor de entrada simples e exibir um intervalo simples com o texto inserido pode ser mais rápido por meio de uma estrutura do que acessar diretamente esse elemento?”

Isso o motivou a encontrar uma solução mais próxima da plataforma do navegador.

“Acontece que sentimos que nossas necessidades não estão mais alinhadas com o paradigma React”, ele me disse, acrescentando: “Enfatizo que este é um caso específico para nós”.

Implementando a abordagem da API DOM nativa

Após várias tentativas de modificar a estrutura de seu aplicativo, Moulis e sua equipe eventualmente “optaram por se aproximar das APIs DOM nativas”.

“Ficamos completamente surpresos com o ganho de velocidade.”

“Para fazer isso, configuramos um servidor SSR simples (Node) para pré-renderizar nossos objetos de back-end e produzir nossos componentes por meio de um analisador de string de modelo simples e um mapa”, disse ele.

Aqui está uma visão geral do que a equipe Mindsapp fez, de acordo com Moulis:

“Para conseguir isso, nosso componente Link envia solicitações diretamente ao servidor SSR. Se a resposta for correta, o SSR devolve a página; se houver algum erro, ele envia uma página 500 ou 404, que podemos configurar no nosso criador de páginas. Também configuramos um RxJS fromEvent simples diretamente no objeto window para lidar com a navegação nativa do navegador, que também envia solicitações ao servidor SSR.

A implementação levou um mês, mas os resultados foram imediatamente visíveis depois disso.

“Ficamos completamente surpresos com o ganho de velocidade”, disse Moulis. “Nosso mecanismo de aplicação foi projetado para produzir aplicações complexas do tipo ERP, que envolvem grande consumo de dados para serem apresentadas em tempo real. Em uma página que consideramos complexa, com mais de 800 elementos DOM, alguns dos quais usam diferentes sistemas de assinatura através do nosso sistema de eventos na inicialização para atualizar quando necessário, o tempo geral de carregamento caiu de 4-5 segundos para 400ms.”

“Em termos de interação, chega de verificações intermináveis ​​para garantir que um filho não seja atualizado, mesmo que o estado pai seja atualizado.”

Além dos ganhos de velocidade, as interações dos usuários melhoraram significativamente, disse Moulis.

“Em termos de interação, chega de verificações intermináveis ​​para garantir que um filho não seja atualizado, mesmo que o estado pai seja atualizado. Um exemplo simples e trivial: um usuário pode querer alterar a cor de fundo de um cartão ao clicar, que contém um gráfico. Podemos fazer isso sem nos preocupar com a atualização do gráfico ou não.”

Desvantagens

Moulis reconheceu, no entanto, que a abordagem HTML-first vem com bagagem. Ele descreve os Web Components como “muito detalhados” e observa que “nos tornamos responsáveis ​​por garantir (que) todas as assinaturas feitas pelos elementos sejam devidamente limpas quando os elementos são destruídos”.

Ele acrescentou que encontrar desenvolvedores que conheçam JavaScript básico e não apenas os frameworks foi uma “dificuldade inesperada”.

“No entanto”, disse ele, “o ganho do usuário é enorme e essa sempre foi nossa prioridade”.

São necessárias mais histórias pós-reação

Se você ou sua empresa também migraram do React para uma abordagem mais nativa da web e com foco no HTML, marque-me no Mastodon ou Threads. Adoraríamos compartilhar mais estudos de caso desses modernos, ouso dizer pós-Reagiraproxima-se.

Na verdade, marque-me também se você não acha que o React deveria ser abandonado – qual é o seu caso?

A postagem Pivotando do React para APIs DOM nativas: um exemplo do mundo real apareceu pela primeira vez em The New Stack.