[PARTE 1] Next.js 13: Estratégias de renderização com Pages Router vs App Router

Nivelando o conhecimento

Mesmo que você tenha chegado agora ao mundo do Next.js é muito importante saber o funcionamento e as diferenças entre o App Router e o Pages Router, é crucial entendermos as estratégias de renderização e como elas são “representadas” em cada Router.

Antes de prosseguir precisamos relembrar alguns conceitos para um entendimento pleno das estratégias de renderização. Quando falamos de React e Next.js, diversas vezes nos deparamos com os termos renderização (rendering), pré-renderização (pre-rendering) e hidratação (hydration), ter um entendimento claro desses conceitos é crucial:

• Renderização: É o processo que o React realiza para converter o código em HTML, tornando assim possível que o navegador possa "desenhar a interface" na tela.

• Pré-renderização: É o processo que o Next.js realiza para converter o código em HTML, porém, executa este processo no lado do servidor.

• Hidratação: É o processo que o React realiza para "injetar" os valores do JSON e as instruções JavaScript no HTML renderizado, tornando assim a página interativa.

Você pode entender renderização e pré-renderização como o mesmo processo, sendo "pré-renderização" uma nomenclatura adotada pelo Next.js para oferecer uma melhor explicação. Em resumo, enquanto o React so tem a capacidade de executar a renderização no lado do cliente, o Next.js executa este mesmo processo no lado do servidor, deixando a cargo do lado do cliente apenas a hidratação.

Ao adotar essa estratégia o Next.js oferece duas grandes vantagens em relação a um projeto "React puro" criado utilizando, por exemplo, o Create React App:

1. Melhor performance, pois uma parte do processamento para "criar a página" é realizado no lado do servidor.
2. Melhor experiência para o usuário, pois ao invés de exibir uma "tela branca" enquanto a página é renderizada no lado do cliente, é imediatamente exibido o HTML pré-renderizado no lado servidor, fazendo com que o lado do cliente tenha apenas que aguardar o processo de hidratação para que a página se torne interativa. É interessante ressaltar que ao desativar o JavaScript do navegador o HTML continua sendo exibido, fazendo com que apenas a parte interativa não funcione.

Importante saber

Uma página gerada estaticamente e salva em uma CDN significa que quando requisitada já possui seu HTML pré-renderizado salvo em um storage e apenas precisa enviá-lo para o cliente, não necessitando nenhum processamento no lado do servidor para pré-renderizar a página.

Entendidos esses conceitos, vamos falar sobre as estratégias de renderização disponíveis em cada Router do Next.js!

Pages Router

• Static Site Generation (SSG): O HTML é pré-renderizado no lado do servidor durante o processo de build, o resultado é salvo em uma CDN, enviado e hidratado no lado do cliente. Uma página usa esta estratégia quando:
  • Não exporta nenhuma função.
  • Exporta a função getStaticProps com a propriedade revalidate: false (Padrão).
  • Não é uma Dynamic Route.
• Incremental Static Regeneration (ISR): O HTML é pré-renderizado no lado do servidor durante o processo de build de acordo com as regras de revalidação de cache estabelecidas, o resultado é salvo em uma CDN, enviado e hidratado no lado do cliente. Uma página usa esta estratégia quando:
  • Exporta a função getStaticProps com a propriedade revalidate com o valor maior que 0.
  • Invoca a função res.revalidate(‘/path-to-revalidate’).
  • É uma Dynamic Route e exporta as funções getStaticProps e getStaticPaths.
• Server-side Rendering (SSR): O HTML é pré-renderizado no lado do servidor a cada requisição, enviado e hidratado no lado do cliente. Uma página usa esta estratégia quando:
  • Exporta a função getServerSideProps.
  • Exporta a função getInitialProps (Legado).
• Client-side Rendering (CSR): O HTML é pré-renderizado no lado do servidor a cada requisição, enviado e hidratado no lado do cliente. Uma página usa esta estratégia quando:
  • Não exporta as funções getServerSideProps, getInitialProps (Legado) ou getStaticProps.
  • Busca os dados necessário e atualiza a tela no lado do cliente através de Effects ou utilizando bibliotecas especializadas como SWR ou TanStack Query (Recomendado).

Pontos importantes

• Independente da estratégia utilizada todas as páginas são reativas, já que o processo de hidratação sempre acontece no lado do cliente, isto quer dizer que você pode utilizar States, Events, Effects e APIs do navegador.
• Quando uma página gerada estaticamente é requisitada mas ainda não foi gerada, não necessariamente retornará uma página de Not Found, sendo possível gerá-la pela primeira vez definindo a propriedade fallback da função getStaticPaths para true ou 'blocking'.

Parte 2: App Router

Continue a leitura na parte 2.

Sinta-se a vontade para fazer críticas, sugestões ou tirar dúvidas nos comentários. Vlw!!!