Panoramica

In gt-next 6.2.0, abbiamo compiuto un grande passo avanti nel trasferire l'elaborazione dal runtime alla fase di build tramite un plugin SWC. Questo approccio rende possibili nuove funzionalità come l'hashing in fase di compilazione, le traduzioni pre-renderizzate e una validazione più rigorosa, il tutto senza aggiungere overhead a runtime.

Per concentrarci sull'essenziale, abbiamo iniziato con tre miglioramenti chiave.

• Hashing in fase di compilazione
• Traduzione su richiesta
• Regole di linting in fase di build

Hashing in fase di compilazione

Pur essendo un'ottimizzazione relativamente piccola, ora eseguiamo il calcolo degli hash in fase di build anziché a runtime. Funzioni come getGT() e <T> lato server non devono più calcolare e memorizzare nella cache gli hash a ogni chiamata, garantendo prestazioni più costanti.

Traduzione on demand

Uno dei problemi principali 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 gt = useGT()
  // const gt = await getGT(); per il lato server

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

Abbiamo deliberatamente mantenuto gt() sincrono per allinearlo alle altre librerie i18n. Lo svantaggio era un processo di traduzione in due fasi:

1. Registrare il testo con l'API. 2. Attendere un secondo rendering 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 dover ricaricare la pagina.

Linting in fase di build

In precedenza, per rilevare l'uso non corretto dei componenti <T> era necessario eseguire gtx-cli con un linter personalizzato. Questo creava incoerenze tra il comportamento in sviluppo e in produzione.

Con la versione 6.2.0, le regole di linting vengono ora applicate direttamente nel plugin SWC. Se un contenuto traducibile non è racchiuso in un componente <T>, riceverai un errore in fase di build, così i problemi verranno individuati subito.

Perché SWC (per ora)?

La nostra transizione dal runtime alla fase di build è ancora agli inizi. Stiamo iniziando con Next.js, ma prevediamo di supportare presto anche altri framework. I plugin Babel che offrono 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 in fase di build, riduciamo la complessità a runtime e rendiamo le traduzioni più immediate e prevedibili.