JavaScript sob demanda: como o Qwik difere do React Hydration

Neste post tentarei explicar a retomada, a abordagem do Qwik para resolver o terrível problema de JavaScript do lado do cliente. Também explicarei como ele difere do React.

Há uma ótima introdução ao Qwik em QwikSchool.com, que cobre algumas das áreas que descreverei neste artigo. Mas para mim, ler é a forma como aprendo melhor e aprendo mais rápido quando consigo ver uma comparação identificável, que é o que tentarei fazer agora usando um bar e litros de cerveja. 🍺

Como funciona a hidratação do React?

Imagine que você entra em um bar e se senta, mas o garçom não pergunta o que você quer beber, apenas serve seis litros de cerveja em um copo gigante. Quando estão convencidos de que o copo pode conter seis litros de cerveja, eles a despejam. Eles então passam o copo vazio para você (o cliente) e colocam mais seis litros de cerveja no copo.

Você será solicitado a pagar por 12 litros, seis dos quais foram descartados e cinco dos quais você provavelmente não precisará imediatamente.

É assim que funciona a hidratação do React!

Como funciona a capacidade de retomada do Qwik?

Imagine que você entra em um bar e se senta, e o garçom pergunta o que você gostaria de beber. Você responde: “Um litro de cerveja, por favor”. O garçom então despeja meio litro em um copo de tamanho normal e o entrega a você.

Você será solicitado a pagar por meio litro. E essa é a capacidade de recuperação do Qwik em poucas palavras (ou copo de cerveja, neste caso).

Em um nível muito alto, você verá que com o React há muito desperdício e não há um método excessivamente preciso para determinar o que você quer ou quando quer.

Replay de hidratação do React

Usando o exemplo acima novamente, você deve ter notado que o garçom despejou seis litros de cerveja em um copo gigante, depois despejou-o deixando apenas um copo vazio que foi entregue a você (o cliente) e depois o encheu novamente.

Quando o React é renderizado no servidor, é isso que acontece. O aplicativo é construído no lado do servidor e depois descartado. O servidor irá, no entanto, enviar o HTML para o cliente, seguido por um pedaço de JavaScript que é usado para reproduzir efetivamente as mesmas etapas, só que desta vez no cliente (navegador). Se por algum motivo a repetição não for bem-sucedida, você verá erros de hidratação no seu console.

O servidor precisa construir a página uma vez, para saber o que enviará ao cliente – o que explica metade da repetição da hidratação, mas você pode ficar se perguntando por que, na minha analogia com a cerveja, todos os 6 litros foram servidos de uma vez só? Também me perguntei sobre isso, e a resposta está na “repartição de rotas”.

O que é fragmentação de rota?

Isso dependerá um pouco de qual estrutura React você está usando, mas quando um aplicativo React é construído no servidor, a estrutura descobrirá qual JavaScript incluir com base na rota em que o usuário está. Por exemplo, se estiverem em uma rota /dashboard, precisarão de um JavaScript diferente do que se estivessem em uma rota /settings. Dependendo da rota, determinará quais partes do JavaScript do seu aplicativo serão incluídas no bloco. Isso é algo muito inteligente, mas poderia ser ainda mais inteligente.

O que é fragmentação dinâmica de componentes?

A abordagem do Qwik é muito mais granular. Em vez de determinar qual JavaScript incluir com base na rota em que o usuário está, ele divide o JavaScript em pedaços muito menores. Essas peças menores podem então ser entregues ao cliente com muito mais rapidez; e mais do que isso, o Qwik é capaz de determinar em que ponto durante a visita de um usuário a qualquer rota ele pode precisar desses pedaços menores de JavaScript.

Eu preciso de um Dollar

Tudo no Qwik usa o sufixo $. Por exemplo, este componente simples é encapsulado com component$().

import { component$, $ } from '@builder.io/qwik';

const SimpleQwikComponent = component$(() => {
    
  const handleClick = $(() => {
    console.log('Hello world!');
  });

  return (
    <div>
      <p>Hello, I'm a simple Qwik component</p>
      <button onClick$={handleClick}>Click me</button>
    </div>
  );
});

export default SimpleQwikComponent;

Usando a sintaxe $, o Qwik é mais facilmente capaz de otimizar os limites de chunking – o que resulta em pedaços JavaScript individuais menores.

Além disso, ele é capaz de servir esses pedaços menores como e quando necessário.

Pegue isso onClick$, por exemplo. O JavaScript para fazer isso funcionar só será necessário se o usuário realmente clicar no botão. Se um usuário não clicar no botão, o JavaScript necessário para exibir “Olá, mundo!” no console existirá apenas no cache do navegador (que foi buscado pelo service worker do Qwik), ele não terá sido buscado e baixado com entusiasmo até que seja realmente necessário.

Amplie esse pensamento para um aplicativo muito maior, com muitas áreas diferentes de interatividade e pergunte-se: todos os usuários precisam de todo o JavaScript, o tempo todo? Ou alguns usuários precisam apenas de parte do JavaScript, algumas vezes?

O trabalhador de serviço

É aqui que as coisas ficam realmente interessantes. Você deve estar familiarizado com o Partytown, um projeto de código aberto dos criadores do Qwik que permite transferir o carregamento de scripts do lado do cliente para coisas como o Google Analytics para um service worker. Ao descarregar scripts não essenciais para um service worker, você libera o thread principal do navegador, que pode então ser usado para carregar com mais eficiência o código do aplicativo que alimenta um aplicativo.

Mas…

Por padrão, o Qwik usa um service worker para carregar o código real do aplicativo! E talvez, em uma dimensão alternativa, isso significaria que você poderia continuar a carregar o Google Analytics no thread principal com implicações limitadas no desempenho. 🤷

Depois que o JavaScript é carregado pelo service worker, ele é armazenado em cache pelo navegador; portanto, da próxima vez que um usuário fizer algo que possa reutilizar o código que já foi baixado, o Qwik o carregará do cache, e não pela rede. É neste ponto que minha analogia com a cerveja fica um pouco confusa, mas… espero que você entenda o que quero dizer.

Um exemplo educado

Para dar um exemplo, em cada uma das páginas de “postagem” do meu site, tenho um componente Reações.

Se parece com isso.

Este componente é responsável pelo seguinte:

• Faça uma solicitação do lado do cliente para OBTER o total de reações enviadas para a postagem atual.
• Clique nos manipuladores para fazer uma solicitação POST do lado do cliente para enviar uma reação.

Mas graças ao Qwik, a maneira como ele faz isso é bastante inteligente.

Permita-me explicar. Aqui está uma captura de tela da guia de rede da mesma postagem:

Até agora, há apenas cerca de 19kb de JavaScript carregado nesta página (esse é o código principal do Qwik).

Role um pouco mais para baixo, quando o componente Reaction entra na janela de visualização e o Qwik carrega os pedaços individuais de JavaScript necessários para exibir os rostos sorridentes e inicia uma solicitação GET do lado do cliente para os totais.

Mas espere, tem mais.

Interaja com o componente Reactions (que faz uma solicitação POST) e você notará que o Qwik mais uma vez carrega os pedaços individuais de JavaScript necessários para ativar essa funcionalidade.

Cada um desses pedaços é muito pequeno; no meu caso, a maioria tem menos de um único kilobyte (KB)!

Pensamento rápido

E esse é o pensamento de Qwik. Carregue apenas o JavaScript necessário; mas mais importante ainda, quando for necessário. Isso é de particular importância para algo como este componente Reactions, que está bem na parte inferior do que na verdade é uma “página estática” – o que significa que não há busca ou renderização de dados no lado do servidor e carregará mais rápido do que uma página SSR, mas ainda assim precisa executar as funcionalidades GET e POST.

Em muitos casos, os leitores das minhas postagens nunca irão rolar até o final da página, então não há necessidade de nenhum desses dados – ou do JavaScript ser carregado. Mas, quando/se isso acontecer, o Qwik intervém e decide de forma inteligente o que e quando carregar. É genial!

Reagir Cérebro

É possível, claro, conseguir a mesma coisa usando React (mais ou menos). Você poderia escrever seu próprio observador de interseção e combiná-lo com o preguiçoso/suspense do React para que a busca de dados (e o JavaScript necessário para permitir a interatividade) ocorra apenas se o componente for rolado para dentro da janela de visualização; mas essas são coisas nas quais você, como desenvolvedor, precisa pensar e otimizar, enquanto o Qwik faz tudo isso pensando por você!

Pensamentos finais

Embora a analogia do bar e da cerveja possa parecer um pouco estranha, acredito que em termos práticos a teoria se sustenta. Você/o usuário apenas faz o pedido e pagar para o que você quer quando você quer isso.

E, honestamente, por que deveria ser diferente com o código do aplicativo? Não faz sentido desperdiçar metade e depois entregar e cobrar demais, sem nem mesmo pedir. Na verdade, o que todos nós queremos é simplesmente pagar pelo que pedimos.

Há uma explicação técnica escrita pela equipe do Qwik nos documentos, você provavelmente deveria ler isso também: Resumable vs. Hidratação. Mas se você gosta do som do Qwik, dê uma olhada! Eu me diverti muito aprendendo o Qwik e sempre fico surpreso com o quão pouco preciso pensar nas coisas para obter um desempenho absolutamente incrível.

A postagem JavaScript sob demanda: como o Qwik difere do React Hydration apareceu pela primeira vez no The New Stack.