Estratégias de obtenção de dados no NextJS

Pawel Rybczynski

Software Engineer

Recentemente, o NextJS está a ganhar cada vez mais popularidade como forma de construir aplicações React. Certamente, um dos principais contribuintes é o facto de o NextJS oferecer várias estratégias diferentes de obtenção de dados.

E estes são:

Renderização do lado do cliente: CSR,
Renderização do lado do servidor: SSR,
Renderização de sítios estáticos: SSG,
Regeneração estática incremental: ISR.

NextJS, ao contrário do simples React oferece uma funcionalidade chamada pré-renderização. Isto significa que o HTML pré-renderizado é apresentado durante o carregamento inicial. Nas aplicações React tradicionais, toda a aplicação é carregada e processada no lado do cliente. Depois, após o JS código é carregada, a aplicação torna-se interactiva.

Geração estática

No SSG, o HTML é gerado em tempo de compilação e reutilizado para cada pedido. Após a criação de uma compilação de produção, cada pedido irá reutilizar esse ficheiro HTML gerado estaticamente.

Existem também dois tipos de geração estática: com e sem dados.

No primeiro caso, o HTML será gerado depois de obter os dados através da resolução da promessa. Nesse caso, podemos usar o método de obtenção de dados getStaticProps... mas somente se você estiver usando o Next.js 9.3 ou mais recente. Caso contrário, pense em atualizá-lo, pois o método antigo getInitialProps não é mais recomendado e será descontinuado. Esse método também é chamado em todas as navegações do lado do cliente, portanto, não é eficiente se você não quiser buscar dados em cada solicitação.

exportar a função assíncrona getStaticProps() {
  const res = await fetch("https://jsonplaceholder.typicode.com/posts");
  const posts = await res.json();
  return {
    props: { posts },
  };
}

O que é realmente fixe é uma funcionalidade recentemente lançada chamada ISR (Incremental Static Regeneration), que é algo entre o SSG e o SSR. Permite-lhe (utilizando uma chave específica chamada revalidate) fazer com que a página seja regenerada de forma incremental. Isto significa que, com esta chave, não é necessário reconstruir a aplicação de cada vez que se pretende obter uma atualização dos dados obtidos a partir do servidor. Basta adicionar a chave revalidate com o período de revalidação em segundos.

exportar a função assíncrona getStaticProps() {
  const res = await fetch("https://jsonplaceholder.typicode.com/posts");
  const posts = await res.json();
  return {
    props: {
      posts,
    },
    revalidate: 30,
  };
}

Isso significa que, se os pedidos forem feitos após esse período, o servidor irá buscar os dados novamente.

Outra situação é quando se utiliza uma página dinâmica e o caminho depende de alguns dados externos. Nesse caso, podemos usar o método getStaticPaths informando quais rotas dinâmicas devem ser pré-carregadas:

exportar async const getStaticProps = ({ params }) => {
  const res = await fetch(`https://jsonplaceholder.typicode.com/posts/${params.id}`);
  const post = await res.json();
  return {
    props: { post },
  };
}

exportar a função assíncrona getStaticPaths() {
  const res = await fetch("https://jsonplaceholder.typicode.com/posts");
  const posts = await res.json();
  const paths = posts.map(({ id }) => ({ params: { id: `${id}` } }));
  return {
    paths,
    fallback: false,
  };
}

Existe uma boa maneira de verificar quais rotas dinâmicas foram criadas. Pode executar a próxima compilação e a próxima exportação e, depois disso, terá uma versão estática da sua aplicação no recém-criado diretório out.

Vamos agora limitar os caminhos de pré-compilação:

exportar a função assíncrona getStaticPaths() {
  return {
    paths: [{ params: { id: "1" } }, { params: { id: "2" } }],
    fallback: false,
  };
}

Depois de executar a exportação seguinte, podemos observar em ambos os casos (com e sem um número limitado de caminhos) um número diferente de mensagens encontradas em my-appoutposts.

Vamos agora dar uma olhada mais de perto no parâmetro de fallback crucial e obrigatório. Ele diz o que fazer se a página não foi pré-renderizada no momento da construção. Se for definido como true, o getStaticProps é executado e gera essa página. Se for falso, obtemos o erro 404 ao tentar carregar esse caminho específico. Outra coisa: as páginas com fallback que estão activadas em getStaticPaths não podem ser exportadas.

Abaixo pode ver os resultados da tentativa de carregar a mesma página dinâmica em ambos os casos:

Primeiro caso (sem trajectórias limitadas)

Segundo caso (com caminhos limitados e recurso definido como falso)

Segundo caso (com caminhos limitados e fallback definido como verdadeiro)

Renderização do lado do servidor

A principal diferença em relação ao SSG: é gerado um novo HTML em cada pedido. É utilizado principalmente quando estamos a obter alguns dados externos. Neste caso, não é necessário reconstruir a aplicação sempre que quisermos atualizar os dados do servidor.

exportar a função assíncrona getServerSideProps() {
  const res = await fetch("https://jsonplaceholder.typicode.com/posts");
  const posts = await res.json();
  return {
    props: {
      posts,
    },
  };
}

O método getServerSideProps é muito semelhante ao getStaticProps. A diferença é que getServerSideProps é executado em cada pedido, enquanto getStaticProps é executado uma vez em tempo de compilação.

Renderização do lado do cliente

Com a renderização do lado do cliente, o carregamento inicial da página é um pouco lento. A comunicação com o servidor ocorre em tempo de execução. Pode fazê-lo de uma forma mais tradicional:

const Blog = () => {


 const [posts, setPosts] = useState([]);
  useEffect(() => {
    const fetchData = async () => {
      const res = await fetch(
     "https://jsonplaceholder.typicode.com/posts");
      const posts = await res.json();
      setPosts(posts);
    };
    fetchData();
  }, []);

Além disso, podemos utilizar outra solução, 'swr' - Ganchos React para busca de dados da Vercel*, que é fortemente recomendada pelos criadores do NextJS. A sigla SWR significa State While Revalidate.

^* Fonte de dados: SWR por Vercel

import useSWR from "swr";


const Blog = () =&gt; {
 const fetcher = (url) =&gt; fetch(url).then((r) =&gt; r.json());
 const { data: posts = [], error } = useSWR(
    "https://jsonplaceholder.typicode.com/posts", fetcher);
 se (erro) return <div>Falha no carregamento de mensagens</div>;
 se (!posts.length) return <div>carregando...</div>;
 retorno (
    <>
      {posts.map((post) =&gt; (
            {post.title}
        ))}
    </>
}

Resumo

NextJS dá nós a possibilidade adicional de escolher qual das estratégias de obtenção de dados queremos utilizar em cada página. Não precisamos de seguir apenas uma solução para toda a aplicação.

Atalho

getServerSideProps - quando é necessário pré-renderizar a aplicação em cada pedido com dados obtidos
getStaticProps - quando os dados podem ser obtidos uma vez em tempo de construção e utilizados em cada pedido sem atualização
getInitialProps - não recomendado, será descontinuado
getStaticPaths - para pré-renderização de caminhos dinâmicos