Panoramica

In gt-next 6.2.0 abbiamo compiuto un grande passo verso lo spostamento dell'elaborazione dal runtime al build time tramite un plugin SWC. Questo approccio sblocca nuove funzionalità come l'hashing in fase di compilazione, traduzioni prerenderizzate e una convalida più rigorosa — il tutto senza aggiungere overhead a runtime.

Per rimanere focalizzati, abbiamo iniziato con tre miglioramenti chiave.

• Hashing in fase di compilazione
• Traduzione on demand
• Regole di linting in fase di build

Hashing in fase di compilazione

Anche se si tratta di un'ottimizzazione relativamente piccola, ora eseguiamo i calcoli degli hash in fase di build invece che a runtime.
Funzioni come getGT() e il componente <T> lato server non devono più calcolare e memorizzare nella cache gli hash a ogni chiamata, con conseguenti prestazioni più uniformi.

Traduzione on‑demand

Uno dei problemi più grandi per gli sviluppatori è sempre stato dover ricaricare la pagina durante lo sviluppo per vedere in tempo reale gli aggiornamenti delle stringhe.

getGT() e useGT() seguono il consueto pattern i18n:

export default function Page() {
  const t = useGT()
  // const t = await getGT(); per il lato server

  return (
    <>
      {t('contenuto da tradurre')}
      {t('altro contenuto da tradurre')}
    </>
  )
}

Abbiamo deliberatamente mantenuto t() sincrona per allinearla ad altre librerie i18n. Lo svantaggio era un processo di traduzione in due fasi:

1. Registrare il testo tramite l'API. 2. Attendere un secondo render per visualizzare il risultato tradotto.

Ora, grazie al compilatore, il contenuto traducibile viene analizzato in anticipo e passato direttamente a useGT() o getGT() in fase di compilazione. Questo significa che le traduzioni sono immediatamente disponibili a runtime, senza ricaricare la pagina.

Linting in fase di build

In precedenza, per rilevare un uso errato dei componenti <T> era necessario eseguire gtx-cli con un linter personalizzato. Questo generava incoerenze tra il comportamento in development e in production.

Con la versione 6.2.0, le regole di linting vengono ora applicate direttamente nel plugin SWC. Se del contenuto traducibile non è racchiuso in un componente <T>, verrà generato un errore in fase di build, così che i problemi vengano individuati il prima possibile.

Perché SWC (per ora)?

La nostra transizione dal runtime al build time è ancora nelle fasi iniziali. Stiamo partendo da Next.js, ma prevediamo di supportare presto altri framework. I plugin di Babel che offriranno la stessa funzionalità sono già in roadmap.

gt-next 6.2.0 getta le basi per un flusso di lavoro di traduzione più rapido e affidabile. Spostando la logica al build time, riduciamo la complessità a runtime e rendiamo le traduzioni più immediate e prevedibili.