Next.js 9.1

Hoy estamos emocionados de anunciar Next.js 9.1 con soporte para los directorios src y public.

Novedades en esta versión

• Soporte para directorio src: El directorio pages ahora puede anidarse dentro de la carpeta src, admitiendo una mayor variedad de configuraciones de aplicaciones.
• Soporte para directorio public: Define archivos para montarse en la raíz de la URL de tu aplicación (ej. favicon.ico).

Vista previa en esta versión

• Soporte CSS integrado: Pronto las aplicaciones podrán importar CSS Global y aprovechar la recarga en caliente en desarrollo y optimizaciones avanzadas de producción, compilación y polyfilling.
• Páginas de error estáticas: Exporta estáticamente páginas de error esperadas (como 404) para mejor disponibilidad (CDN).
• Module / Nomodule: Envía paquetes JavaScript más pequeños a usuarios con navegadores modernos.
• Mejor división de paquetes: Envía menos bytes al usuario final, mejorando TTI y velocidad de transición entre páginas. Los fragmentos grandes de bibliotecas también se almacenan en caché a largo plazo entre despliegues.

Como siempre, nos esforzamos por garantizar que todos estos beneficios sean compatibles con versiones anteriores. Todo lo que necesitas para actualizar es ejecutar:

npm i next@latest react@latest react-dom@latest

Si tu aplicación está en una versión de Next.js anterior a la 9, puedes consultar la guía de actualización para ver los cambios que podrías necesitar.

Desde nuestro último lanzamiento importante, nos alegra haber visto empresas como TikTok, Hilton, Elastic, Realtor y JW Player lanzarse con Next.js. ¡Consulta el showcase para ver más!

Soporte para directorio src

Next.js tiene un directorio especial pages donde cada archivo se convierte en una ruta separada, siguiendo el enfoque de convención sobre configuración, este directorio debe estar en la raíz de una aplicación Next.js.

Al hablar con empresas que usan Next.js e inspeccionar algunos repositorios de código cerrado, establecimos que un patrón común que los desarrolladores deseaban era tener un directorio src para su código y tener el directorio pages dentro también.

A partir de Next.js 9.1, ahora es posible crear un directorio src/pages en lugar de crear un directorio pages en la raíz de la aplicación.

Usar el directorio src es opcional y cubre el caso donde tu empresa ya tiene este estándar implementado.

La carpeta pages dentro del directorio src

Soporte para directorio public

Además del directorio pages, Next.js tiene otro directorio especial llamado static, cuyos archivos se mapeaban a la ruta /static.

Por ejemplo, static/mi-imagen.png se mapearía a /static/mi-imagen.png.

Esta convención ha funcionado bien desde el primer lanzamiento de Next.js y no tiene problemas particulares.

Sin embargo, con el tiempo hemos establecido que /static no cubre todo lo necesario en una aplicación web. Por ejemplo, robots.txt debe servirse desde la raíz del dominio.

A partir de Next.js 9.1 estamos introduciendo un nuevo directorio llamado public.

Cualquier archivo en el directorio public se mapeará a la raíz del dominio.

Por ejemplo, public/robots.txt se mapeará a /robots.txt.

Dado que public también cubre el caso de uso del directorio static, hemos decidido dejar obsoleto el directorio static en favor de crear una carpeta public/static con la misma funcionalidad.

Como siempre, nos esforzamos por la compatibilidad con versiones anteriores, por lo que el directorio static seguirá funcionando con un mensaje de obsolescencia.

Próximamente

Las siguientes características están actualmente bajo una bandera experimental y se lanzarán una vez que la implementación final esté lista.

Soporte CSS integrado

Actualmente, Next.js tiene una solución CSS-in-JS integrada llamada styled-jsx. Esta solución funciona bien para estilizar componentes React individuales.

Sin embargo, al hablar con empresas, encontramos que existe una necesidad común de reutilizar algún estilo existente o un sistema de diseño basado en CSS.

En general, esto significa agregar el plugin next-css para agregar soporte de importación de CSS.

Descubrimos que alrededor del 50% de todos los usuarios de Next.js agregan este plugin a su aplicación.

Debido a este uso extensivo, estamos agregando soporte integrado para importaciones CSS con recarga automática de estilos en desarrollo y optimizaciones de producción que antes no eran posibles en el plugin next-css.

La implementación inicial se está probando actualmente en aplicaciones Next.js de producción.

Primero se introducirán las importaciones CSS globales:

// Los estilos globales se pueden importar desde _app.js
import '../styles/global.css';
import App from 'next/app';
 
export default App;

Después de las importaciones CSS globales, introduciremos soporte para módulos CSS a través de la extensión .module.css:

// Los estilos con alcance se importan a través de .module.css
import styles from '../styles/index.module.css';
 
export default function HomePage() {
  return <h1 className={styles.heading}>Hola Mundo</h1>;
}

Esto nos permitirá proporcionar una experiencia de desarrollador significativamente mejor al usar importaciones CSS.

Puedes leer más sobre el trabajo en curso en el RFC en GitHub.

Páginas de error estáticas

Next.js tiene una página especial que se renderiza cuando ocurre un error, esta página se llama internamente /_error. Esta página puede ser personalizada por los usuarios creando un archivo pages/_error.js que exporte un componente React.

Los errores renderizados generalmente se dividen en 2 casos: errores esperados y errores inesperados.

Los errores esperados son, por ejemplo, la página 404.

Un error inesperado sería, por ejemplo, cuando se lanza un error en getInitialProps o mientras se renderiza el árbol React, lo que renderiza un 500.

Estamos planeando agregar la optimización estática automática para errores esperados, ya que en general no tienen que renderizarse dinámicamente.

Habrá una opción para optar por no participar si un usuario quiere renderizar estas páginas dinámicamente, pero por defecto 404 será una página estática. Esto reduce la carga en el servidor cuando se usa el objetivo server y reduce costos cuando se usa el objetivo serverless.

Otro beneficio de hacer la página estática es que puede almacenarse en caché automáticamente cuando se usa una CDN.

Colaboración con Google Chrome

Como se compartió en el anuncio de Next.js 9, el equipo de Google Chrome está invirtiendo recursos en mejorar Next.js y ha estado trabajando en múltiples esfuerzos para hacer mejoras de rendimiento a gran escala para todas las aplicaciones Next.js.

Para obtener más información sobre esta colaboración, puedes leer el anuncio de Next.js 9 y ver esta charla de Nicole Sullivan en React Rally.

Module / Nomodule

Cuando escribes código en Next.js generalmente escribes JavaScript "moderno". Puedes usar todas las últimas características estables y Next.js se asegurará automáticamente de que estas características se transformen o se apliquen polyfills compilando el código usando Babel.

En este punto, muchas de estas características de JavaScript son compatibles con la mayoría de los navegadores. Sin embargo, en general (incluyendo en Next.js), el código se envía como un único paquete JavaScript que se ejecuta en todos los navegadores que tu aplicación admite.

En el caso de Next.js, esto significa compilar el JavaScript moderno a un formato compatible con Internet Explorer 11.

Por ejemplo, actualmente Next.js tiene que proporcionar polyfills para la sintaxis async/await ya que el código podría ejecutarse en navegadores que no admiten async/await, lo que causaría un error.

Para evitar romper navegadores antiguos mientras se envía JavaScript moderno a navegadores que admiten sintaxis más nuevas, Next.js utilizará el patrón module/nomodule. El patrón module/nomodule proporciona un mecanismo confiable para servir JavaScript moderno a navegadores modernos mientras permite que navegadores antiguos recurran a código ES5 con polyfills.

Esta nueva característica se está probando actualmente en producción por múltiples aplicaciones Next.js a gran escala para recopilar datos del mundo real. Los resultados de estas pruebas son prometedores y pronto se compartirán más detalles sobre las mejoras de rendimiento de este cambio.

Mejor división de paquetes

Next.js actualmente tiene múltiples paquetes JavaScript que carga para hacer una página interactiva. Los más notables son:

• El paquete JavaScript de la página.
• Un archivo con JavaScript común.
• El paquete de tiempo de ejecución del lado del cliente de Next.js.
• Importaciones dinámicas (generalmente agregadas a través de next/dynamic).

Para garantizar que la página se vuelva interactiva, todos estos paquetes deben cargarse ya que todos dependen entre sí para poder iniciar React en el navegador.

Debido a que estos paquetes son necesarios para cargarse para que React se inicie, es importante que estén lo más optimizados posible y no descarguen demasiado código del resto de la aplicación.

Por esta razón, existe un paquete commons que contiene JavaScript común entre páginas. El cálculo de la estrategia actual de división de paquetes para generar commons se basa en una heurística basada en proporciones: si un módulo se usa en el 50% de todas las páginas, se marcará como un módulo común.

Sin embargo, las aplicaciones podrían constar de muchas partes diferentes. Por ejemplo, páginas de marketing, un blog y un panel. Si hubiera un gran número de páginas de marketing en comparación con el panel, el cálculo de commons causaría un resultado más optimizado para las páginas de marketing.

Nuestro objetivo es optimizar ambos al mismo tiempo en una sola aplicación.

Alex Castle definió una nueva capa de fragmentación (creación de archivos JavaScript separados) que permite un agrupamiento común más optimizado con múltiples archivos y especialmente cuando hay muchas páginas involucradas.

Similar al soporte module/nomodule, la mejor división de paquetes se está probando en producción por múltiples aplicaciones Next.js a gran escala para recopilar datos del mundo real. Los resultados de estas pruebas y más detalles sobre las mejoras de rendimiento de este cambio se compartirán pronto en una publicación de blog separada.

Comunidad

Estamos emocionados por los próximos cambios que mejorarán el rendimiento en todas las aplicaciones Next.js.

Además, la comunidad de Next.js sigue creciendo:

• Hemos tenido más de 800 colaboradores que han realizado al menos 1 commit.
• En GitHub, el proyecto ha recibido más de 41,350 estrellas.
• El directorio de ejemplos tiene más de 210 ejemplos.

La comunidad de Next.js ahora tiene más de 11,250 miembros. ¡Únete a nosotros!

Estamos agradecidos con nuestra comunidad y todos los comentarios y contribuciones externas que ayudaron a dar forma a este lanzamiento.