Introdução

Next.js tem sido uma escolha popular para a construção de aplicativos React renderizados em servidor. Com seu suporte integrado para Server-Side Rendering (SSR), os desenvolvedores podem criar aplicativos dinâmicos e otimizados para SEO. No entanto, a introdução do App Router no Next.js 13 e os refinamentos no Next.js 14 simplificaram e aprimoraram significativamente o SSR.

Nesta postagem do blog, exploraremos as diferenças no SSR entre o sistema tradicional de roteamento de páginas e o sistema mais recente de roteamento de aplicativos, destacando como o SSR funciona e como ele mudou com o novo paradigma de roteamento.

SSR no roteamento de página (Pre-Next.js 13)

Antes da introdução do App Router, o SSR era tratado no sistema Page Routing usando funções específicas como getServerSideProps. Esta função foi chamada em todas as solicitações, permitindo que os desenvolvedores buscassem dados no servidor antes de renderizar a página.

Exemplo de SSR em roteamento de página usando getServerSideProps:

export default function Blogs({ data }) {
  // Render the fetched data
  return (
    

      {data.map((item) => (
        

          
{item.title}
          
{item.content}
        
      ))}
    
  );
}

// This function runs on every request
export async function getServerSideProps() {
  // Fetch data from an external API
  const res = await fetch('https://api.example.com/blogs');
  const data = await res.json();

  // Pass the data as props to the page component
  return { props: { data } };
}

Aqui, getServerSideProps é a chave para SSR no sistema de roteamento de páginas. Ele permite que você busque dados de uma API (ou qualquer outra fonte de dados) em cada solicitação e os passe para o componente da página como acessórios. Esse padrão, embora poderoso, pode resultar em bases de código complexas ao lidar com muita lógica do lado do servidor e rotas diferentes.

Roteamento de aplicativos e SSR em Next.js 14

Com o Next.js 14, o SSR se tornou mais simplificado e integrado ao sistema de roteamento de aplicativos. Este novo sistema introduz componentes de servidor e componentes de cliente, onde o SSR é muito mais intuitivo.

No App Routing, agora você pode buscar dados diretamente dentro de componentes sem precisar de funções especiais como getServerSideProps. Você pode conseguir isso usando ações do servidor, o que torna o código mais simples e fácil de manter.

Exemplo de SSR no roteamento de aplicativos com componentes de servidor:

"use server";

export async function getBlogs() {
  try {
    const response = await fetch('https://api.example.com/posts');
    return response.json();
  } catch (error) {
    return { error: error.message };
  }
}

// This component runs on the server and fetches data
export default async function Blog() {
  const blogs = await getBlogs();

  return (
    

      {(blogs || []).map((blog) => (
        

          
{blog.name}
          
{blog.content}
        
      ))}
    
  );
}

Neste exemplo de App Routing, estamos usando um componente de servidor para buscar dados diretamente dentro do arquivo do componente usando use server. Isso elimina a necessidade de rotas ou funções de API separadas, como getServerSideProps.

O poder das ações do servidor
Next.js 14 simplifica o processo introduzindo ações do servidor. Essas ações permitem que você busque e processe dados diretamente no arquivo do componente, reduzindo a complexidade e tornando sua base de código mais fácil de manter.

Principais benefícios das ações do servidor:

Código mais limpo: Em vez de espalhar a lógica do lado do servidor em arquivos ou funções separadas, você pode manter tudo em um só lugar.
Capacidade de manutenção aprimorada: menos peças móveis significam menos código para gerenciar, tornando seu aplicativo mais fácil de manter.
Melhor desempenho: Com mecanismos de cache inteligentes, você pode ajustar a lógica do lado do servidor para obter desempenho ideal.

Hidratação em Next.js

No contexto de Next.js e renderização do lado do servidor (SSR), hidratação se refere ao processo em que uma página HTML renderizada estaticamente (enviada do servidor) é convertida em um aplicativo React totalmente interativo no navegador. Ele "hidrata" o HTML estático com o JavaScript do lado do cliente do React para tornar a página interativa.

Hidratação no roteamento de aplicativos versus roteamento de páginas

No Page Routing, a hidratação é necessária para cada componente da página, tornando-a interativa no lado do cliente. Isso significa que todo o JavaScript necessário para as interações é enviado ao cliente, o que pode levar a gargalos de desempenho à medida que o aplicativo é dimensionado.

No App Routing, com componentes de servidor, apenas os componentes de cliente (aqueles que lidam com interatividade) são hidratados. Essa hidratação seletiva reduz a quantidade de JavaScript enviada ao cliente, resultando em melhor desempenho.

Exemplo de componentes de cliente no roteamento de aplicativos:

'use client';  // Mark this as a client component

export default function Button() {
  return (
     alert('Button clicked!')}>Click Me
  );
}

Aqui, o componente Button é marcado como um componente cliente com 'use client'. Ele permite interatividade e é executado no lado do cliente, enquanto outros componentes não interativos permanecem como componentes do servidor, melhorando o desempenho.

Mais sobre hidratação no App Routing

Funciona assim:

Componentes pais como componentes de servidor:

Os componentes pai (geralmente os componentes de nível superior ou componentes de página inteira) são normalmente componentes de servidor. Eles são executados no servidor e lidam com coisas como busca de dados, renderização de HTML estático e transmissão desses dados para componentes filhos.
Como são renderizados pelo servidor, eles não incluem nenhum JavaScript no lado do cliente e não são interativos.

Componentes do cliente para interatividade:

Os componentes filhos, que lidam com a interatividade (como botões, formulários, etc.), são componentes do cliente. Esses componentes podem usar ganchos React (useState, useEffect, etc.) e são hidratados no lado do cliente.
Os componentes do servidor passam dados para esses componentes do cliente por meio de props.
Depois que o HTML é carregado no navegador, Next.js hidrata os componentes do cliente, anexando os ouvintes de eventos necessários e tornando a página interativa.

// Server Component (Parent Component)
export default async function ParentComponent() {
  // Fetch data on the server
  const data = await fetch('https://api.example.com/data').then(res => res.json());

  return (
    

      
This is Server-Side Rendered
      
    
  );
}

// Client Component (Child Component)
'use client';

import { useState } from 'react';

function ClientComponent({ data }) {
  const [count, setCount] = useState(0);

  return (
    

      
Data from server: {JSON.stringify(data)}
      
Client-side counter: {count}
       setCount(count   1)}>Increment
    
  );
}

Conclusão

Next.js 14 torna a renderização do lado do servidor (SSR) mais fácil e poderosa com a introdução de ações do servidor no App Router. Ao permitir que os desenvolvedores busquem dados diretamente nos arquivos dos componentes, esse novo sistema agiliza a lógica do lado do servidor, simplifica as bases de código e reduz a necessidade de rotas de API separadas. Juntamente com a hidratação seletiva, o SSR no Next.js 14 agora é mais rápido e eficiente, ajudando você a criar aplicativos altamente dinâmicos e compatíveis com SEO com facilidade.

Ao aproveitar essas ações do servidor, você pode melhorar o desempenho do seu aplicativo enquanto mantém seu código limpo e fácil de manter. A mudança do roteamento de páginas para o roteamento de aplicativos com componentes de servidor e cliente representa um grande salto na construção de aplicativos web escalonáveis.