Recientemente, NextJS está ganando más y más popularidad como una forma de construir aplicaciones React. Sin duda, un factor importante es que NextJS ofrece diferentes estrategias de obtención de datos.
Y estos son:
Renderizado del lado del cliente: CSR,
Renderizado del lado del servidor: SSR,
Representación estática de sitios: SSG,
Regeneración estática incremental: ISR.
NextJS, a diferencia de la aplicación React, ofrece una característica llamada pre-renderizado. Esto significa que el HTML pre-renderizado se muestra durante la carga inicial. En las aplicaciones React tradicionales, toda la aplicación es cargada y renderizada en el lado del cliente. Entonces, después de que el JS código la aplicación se vuelve interactiva.
Generación estática
En SSG, el HTML se genera en tiempo de compilación y se reutiliza para cada solicitud. Una vez creada una compilación de producción, cada solicitud reutilizará ese archivo HTML generado estáticamente.
También hay dos tipos de generación estática: con y sin datos.
En el primer caso, el HTML se generará después de obtener los datos mediante la resolución de la promesa. En este caso, podemos usar el método de obtención de datos getStaticProps... pero sólo si estás usando Next.js 9.3 o superior. Si no, piensa en actualizarlo, porque el antiguo método getInitialProps ya no se recomienda y será obsoleto. Este método también es llamado en cada navegación del lado del cliente, así que no es eficiente si no quieres obtener datos en cada petición.
Lo que realmente mola es una nueva función llamada ISR (Regeneración Estática Incremental), que es algo entre SSG y SSR. Te permite (usando una clave específica llamada revalidate) hacer que la página se regenere incrementalmente. Esto significa que con esta clave no necesitas reconstruir la aplicación cada vez que quieras obtener una actualización de los datos obtenidos del servidor. Sólo tienes que añadir la clave revalidate con el período de revalidación en segundos.
Esto significa que si las solicitudes llegan después de ese período, entonces se obtendrán los datos del servidor de nuevo.
Otra situación es cuando se utiliza una página dinámica, y la ruta depende de algunos datos externos. En ese caso, podemos utilizar el método getStaticPaths indicando qué rutas dinámicas deben ser precargadas:
export async const getStaticProps = ({ params }) => {
const res = await fetch(`https://jsonplaceholder.typicode.com/posts/${params.id}`);
const post = await res.json();
return {
props: { post },
};
}
Hay una buena manera de comprobar qué rutas dinámicas se han creado. Puedes ejecutar la siguiente compilación y la siguiente exportación y después de eso tendrás una versión estática de tu aplicación en el directorio de salida recién creado.
Después de ejecutar la siguiente exportación, podemos observar en ambos casos (con y sin un número limitado de rutas) un número diferente de posts encontrados en my-appoutposts.
Echemos ahora un vistazo más de cerca al crucial y requerido parámetro fallback. Dice qué hacer si la página no fue pre-renderizada en el momento de la compilación. Si se establece en true, el getStaticProps se ejecuta y genera esa página. Si es false, obtendremos 404 después de intentar cargar esa ruta específica. Otra cosa: las páginas con fallback que están habilitadas en getStaticPaths no pueden ser exportadas.
A continuación se muestran los resultados de intentar cargar la misma página dinámica en ambos casos:
Primer caso (sin vías limitadas)
Segundo caso (con rutas limitadas y fallback en false)
Segundo caso (con rutas limitadas y fallback en true)
Renderizado del lado del servidor
La principal diferencia con SSG: se genera nuevo HTML en cada petición. Se utiliza sobre todo cuando obtenemos datos externos. En este caso, no hay necesidad de reconstruir la aplicación cada vez que queremos actualizar los datos desde el servidor.
El método getServerSideProps es muy similar a getStaticProps. La diferencia es que getServerSideProps se ejecuta en cada solicitud, mientras que getStaticProps se ejecuta una vez en tiempo de compilación.
Renderizado del lado del cliente
Con el renderizado del lado del cliente, la carga inicial de la página es un poco lenta. La comunicación con el servidor se produce en tiempo de ejecución. Puedes hacerlo de una forma más tradicional:
También, podemos usar otra solución, 'swr' - React Hooks library for data fetching by Vercel*, la cual es fuertemente recomendada por los creadores de NextJS. SWR significa State While Revalidate.
import useSWR from "swr";
const Blog = () => {
const fetcher = (url) => fetch(url).then((r) => r.json());
const { data: posts = [], error } = useSWR(
"https://jsonplaceholder.typicode.com/posts", fetcher);
if (error) return <div>Error al cargar los mensajes</div>;
if (!posts.length) return <div>cargando...</div>;
devolver (
<>
{posts.map((post) => (
{post.title}
))}
</>
}
Resumen
NextJS nos da la posibilidad adicional de elegir cuál de las estrategias de obtención de datos queremos utilizar en cada página. No necesitamos seguir una única solución para toda la aplicación.
Atajo
getServerSideProps - cuando se necesita pre-renderizar la aplicación en cada petición con los datos obtenidos.
getStaticProps: cuando los datos pueden obtenerse una vez en el momento de la compilación y utilizarse en cada solicitud sin necesidad de actualizarlos.
getInitialProps - no recomendado, será obsoleto
getStaticPaths - para pre-renderizar rutas dinámicas