Next.js 6.1

Hoy nos enorgullece presentar Next.js 6.1 listo para producción, que incluye:

• Mayor confiabilidad en la recarga en caliente (hot reloading)
• Mejoras en la base de código
• Codemods para Next.js

Además del lanzamiento de Next.js 6.1, estamos emocionados de anunciar que nextjs.org es ahora código abierto

Mayor confiabilidad en la recarga en caliente

En versiones anteriores a Next.js 6.1, Next.js implementaba react-hot-loader en nombre del usuario. Esta biblioteca mantiene el estado de React entre recargas en caliente.

Al hacer esto, react-hot-loader añade algunos comportamientos no estándar a React, por ejemplo, ignora shouldComponentUpdate y el type del elemento terminaba siendo un componente proxy en lugar del componente React real.

Para asegurarnos de que Next.js sea lo más cercano posible a React por defecto, hemos eliminado react-hot-loader como dependencia, esto asegura que el modo de desarrollo y producción sean más similares en comportamiento. Cabe destacar que la función de recarga en caliente de Next.js no fue eliminada, esta característica siempre ha sido manejada internamente por Next.js.

Recarga en caliente para Typescript y otras extensiones personalizadas

Por defecto, Next.js busca automáticamente cualquier archivo .js o .jsx dentro del directorio pages para definir rutas.

Con la introducción de webpack universal en Next.js 5 surgió la posibilidad de tener páginas de nivel superior que se compilan a js. Un buen ejemplo es Typescript, que usa .ts y .tsx.

pageExtensions es una clave de configuración en next.config.js destinada a permitir que los plugins de Next.js definan extensiones que deben considerarse páginas. Por ejemplo @zeit/next-typescript define .ts y .tsx o @zeit/next-mdx que documenta cómo tener páginas .mdx de nivel superior.

Anteriormente, al implementar pageExtensions, los plugins de Next.js debían implementar el hot-self-accept-loader que se usa para la recarga en caliente. Esto ya no es necesario, al agregar una extensión a pageExtensions, el hot-self-accept-loader se aplica automáticamente.

Mejoras en la base de código

Recientemente hemos estado preparando el camino para próximas características, esto involucró algunos cambios internos que mejorarán la calidad del código a largo plazo.

Uno de estos cambios es que el directorio server/build se movió al nivel superior build. Esto hace que la configuración de webpack y babel sea más fácil de encontrar para nuevos contribuidores.

También nos hemos enfocado en agregar tipos de Flow en toda la base de código.

Un cambio más visible para los usuarios es que .next/dist ha sido renombrado a .next/server. El directorio .next contiene los resultados de la compilación. Por ejemplo, cuando ejecutas next build, el resultado se almacena en .next.

Los archivos de pre-renderizado ahora están en el directorio server

Las ocurrencias de las mismas constantes se han movido a un archivo común: constants.js

Codemods para Next.js

Cuando se lanzó Next.js 6.0, la propiedad url inyectada mágicamente en los componentes de página fue marcada como obsoleta. La razón por la que url está desapareciendo es que queremos que las cosas sean muy predecibles y explícitas. Tener una propiedad mágica url que aparece de la nada no ayuda a ese objetivo.

La forma recomendada de obtener las mismas propiedades que tenía url es usando withRouter:

// antiguo
class Page extends React.Component {
  render() {
    const { url } = this.props;
    return <div>{url.pathname}</div>;
  }
}
export default Page;

Cómo se accedía al pathname en versiones anteriores a Next.js 6 usando url

// nuevo
import { withRouter } from 'next/router';
class Page extends React.Component {
  render() {
    const { router } = this.props;
    return <div>{router.pathname}</div>;
  }
}
export default withRouter(Page);

Cómo se debe acceder al pathname en versiones posteriores a Next.js 6 usando router inyectado por withRouter

Como estamos comprometidos a mantener el camino de actualización para aplicaciones Next.js simple, nos propusimos crear una forma fácil de actualizar los usos de url a withRouter.

El resultado de este esfuerzo es next‑codemod, una biblioteca de codemods que hacen que actualizar características obsoletas específicas a su nuevo uso sea tan fácil como ejecutar un comando.

El primer codemod que proporcionamos es url-to-withrouter que transforma automáticamente muchos casos donde se usaba url a withRouter.

  jscodeshift -t ./url-to-withrouter.js pages/**/*.js

Esto transformará los usos de url a withRouter.

Leer más aquí

Contribuyendo a Next.js

La comunidad de Next.js está creciendo, con más de 450 contribuidores que ya han enviado al menos 1 commit al núcleo de Next.js o a los ejemplos.

Hay muchas formas de contribuir a Next.js:

• Unirse a la comunidad y dar consejos en GitHub

• Contribuir ejemplos de casos de uso comunes: directorio de ejemplos

• Revisar las etiquetas good first issue y help wanted en GitHub

  

  Hay 30 issues abiertos con la etiqueta good first issue. Dando a nuevos contribuidores la oportunidad de contribuir.

nextjs.org código abierto

Nos complace anunciar que nextjs.org es ahora código abierto para que pueda servir como una implementación de referencia de Nextjs y los problemas/mejoras puedan reportarse directamente en el proyecto.

Futuro

Hemos estado trabajando en algunas nuevas características para aumentar la confiabilidad y el rendimiento, aquí hay algunos aspectos destacados:

Webpack 4

Webpack 4 trae muchas mejoras: mejor división de código (code-splitting), se necesita menos configuración por defecto y, lo más importante, tiempos de compilación más rápidos. En pruebas iniciales que realizamos en una aplicación con más de 200 páginas, next build pasó de tomar 100 segundos a 70 segundos en promedio. En una segunda ejecución (con cachés) un next build tomó 21 segundos en promedio.

Next.js sin servidor (Serverless)

Estamos haciendo cambios incrementales para preparar el traslado de next start a su propio paquete: next-server. Este paquete estará altamente optimizado para el tamaño de instalación y el tiempo de arranque. Estas optimizaciones son necesarias para el caso de uso "sin servidor" donde una nueva instancia de la aplicación se ejecuta por cada solicitud o cada pocas solicitudes. Lo que significa que el "arranque en frío" (cold start) de una aplicación debe optimizarse para ser lo más rápido posible.