Server Components

Breve história

Antes de mergulhar do conceito de Server Components, é importante saber um pouco de como eles surgiram. Bem pouco, eu prometo.

E para saber isso, é preciso se familiarizar com o conceito de Server Side Rendering (SSR) e Client Side Rendering (CSR). Essas são duas técnicas de renderização do websites. Ao renderizar uma aplicação web, o código JavaScript, com que a aplicação foi escrita, é convertido para HTML e CSS, que o navegador usa para exibir a interface de usuário.

Essa conversão pode ocorrer do lado do servidor ou do lado do cliente, o que caracteriza as duas técnicas de renderização.

No SSR, a conversão é feita no servidor, que envia para o cliente o HTML e o CSS, ou seja, a página pronta para ser exibida. No CSR, o servidor envia o código JavaScript para o cliente, que então o converte em HTML e CSS e exibe a interface da página para o usuário.

Por muito tempo, o React só fazia Client Side Rendering. Quando o Next.js surgiu, em 2016, ele trouxe o Server Side Rendering. Essa feature foi muito importante porque impulsiona os sites para os motores de busca (SEO). Ou seja, usando SSR, sua aplicação tem maior chance de aparecer nas buscas do Google e relativos.

Mas, nem tudo são flores. O SSR só era usado em páginas, enquanto os componentes (que compoem as páginas) em si, eram renderizados com CSR. Isso porque a interação do usuário com componentes, como cliques em botões e submits de formulários, necessita do código JavaScript para funcionar. Então somente o CSR serve para esses casos. Eis que, no final de 2020, o React anunciou os Server Components, que prometiam otimizar a renderização em vários aspectos.

Server Components

Os Server Components são componentes que são renderizados com SSR. Com eles, conseguimos enviar menos código JavaScript para o cliente e assim obter mais performance na aplicação. E ainda conseguimos aliar essa performance com a interatividade do CSR.

Fazemos isso separando os componentes interagíveis do nosso Server Component em Client Components. Os Client Components serão pré-renderizados no servidor, então uma preview não-interativa desses componentes é exibida para o usuário. Após isso, eles passam por um processo chamado de hidratação, que é quando o HTML estático recebe o JavaScript necessário para a interação funcionar.

No Next.js

A partir do Next.js 13, usando o App Router, os Server Components são o componente padrão. Ou seja, todo componente criado vai ser renderizado do lado do servidor. Para usar features de interação, é necessário colocar uma diretiva "use client" no início do arquivo do componente.

Colocando essa diretiva, você define o limite entre o que deve ser renderizado de cada lado. Isso porque qualquer componente utilizado num Client Component é tido como parte dele e também é renderizado com CSR. Se for necessário usar Server Components dentro de Client Components, isso só pode ser feito usando a propriedade children do componente.

Ah, e se você tentar usar alguma interatividade num Server Component, o Next.js vai te mostrar um erro tipo esse aqui:

Bem auto-explicativo, né? Só colocar "use client" no topo do arquivo, e voilà.

É importante pensar em sempre ter o mínimo de JavaScript sendo enviado para o cliente, portanto, dividir bem o que precisa ser Client Component e o que não precisa, quando for criar sua árvore de componentes.

Na prática

Veja agora um exemplo de uso de Server Components. Abaixo, há botões para páginas iguais. Todas mostram uma imagem aleatória buscada de uma API. No entanto, uma foi feita com Server Component, outra foi feita 100% com Client Components e a última foi feita utilizando ambos.

Nesses exemplos, os Server Components estão marcados de verde , enquanto os Client Components estão marcados de roxo.