Resumen

En gt-next 6.2.0, hemos dado un gran paso para trasladar el procesamiento del tiempo de ejecución al tiempo de construcción mediante un plugin de SWC. Este enfoque introduce nuevas capacidades, como el hashing en tiempo de compilación, las traducciones prerenderizadas y una validación más estricta, todo ello sin añadir sobrecarga en tiempo de ejecución.

Para mantener el foco, empezamos con tres mejoras clave.

• Hashing en tiempo de compilación
• Traducción bajo demanda
• Reglas de linting en tiempo de construcción

Hashing en tiempo de compilación

Aunque es una optimización relativamente pequeña, ahora realizamos los cálculos de hash durante la construcción en lugar de en tiempo de ejecución. Funciones como getGT() y <T> en el servidor ya no necesitan calcular y almacenar en caché hashes en cada llamada, lo que se traduce en un rendimiento más consistente.

Traducción bajo demanda

Uno de los principales problemas para los desarrolladores ha sido tener que recargar la página durante el desarrollo para ver las actualizaciones de las cadenas en tiempo real.

getGT() y useGT() siguen el patrón habitual de i18n:

export default function Page() {
  const gt = useGT()
  // const gt = await getGT(); para el lado del servidor

  return (
    <>
      {gt('some content to translate')}
      {gt('some other content to translate')}
    </>
  )
}

Mantuvimos deliberadamente gt() como síncrono para mantener la coherencia con otras bibliotecas de i18n. La desventaja era un proceso de traducción en dos pasos:

1. Registrar el texto en la API. 2. Esperar a un segundo renderizado para mostrar el resultado traducido.

Ahora, gracias al compilador, el contenido traducible se analiza previamente y se pasa directamente a useGT() o getGT() en tiempo de compilación. Esto significa que las traducciones están disponibles de inmediato en tiempo de ejecución, sin necesidad de recargar la página.

Linting en tiempo de construcción

Anteriormente, detectar el uso incorrecto de los componentes <T> requería ejecutar gtx-cli con un linter personalizado. Esto generaba inconsistencias entre el comportamiento en desarrollo y en producción.

A partir de la versión 6.2.0, las reglas de linting se aplican directamente en el plugin de SWC. Si algún contenido traducible no está envuelto en un componente <T>, obtendrás un error en tiempo de construcción, lo que garantiza que los problemas se detecten desde el principio.

¿Por qué SWC (por ahora)?

Nuestra transición del tiempo de ejecución al tiempo de construcción todavía está en una fase temprana. Estamos empezando con Next.js, pero pronto tenemos previsto dar soporte a otros frameworks. Los plugins de Babel que ofrecen la misma funcionalidad ya figuran en la hoja de ruta.

gt-next 6.2.0 sienta las bases de un flujo de trabajo de traducción más rápido y fiable. Al trasladar la lógica al tiempo de construcción, reducimos la complejidad en tiempo de ejecución y hacemos que las traducciones sean más inmediatas y predecibles.