概要

gt-next 6.2.0 では、SWC プラグインを通じて、処理を runtime からビルド時へ移すための大きな一歩を踏み出しました。 このアプローチにより、コンパイル時ハッシュ化、翻訳の事前レンダリング、より厳格な検証といった新しい機能が、runtime のオーバーヘッドを増やすことなく実現できるようになります。

焦点を絞るため、まずは 3 つの重要な改善から始めました。

• コンパイル時ハッシュ化
• オンデマンド翻訳
• ビルド時の lint ルール

コンパイル時のハッシュ化

比較的小さな最適化ではありますが、ハッシュ計算をruntimeではなくビルド時に行うようになりました。 これにより、getGT() やサーバーサイドの <T> で、呼び出しのたびにハッシュを計算してキャッシュする必要がなくなり、パフォーマンスがより安定します。

オンデマンド翻訳

開発中、文字列の更新をリアルタイムで確認するために毎回ページを再読み込みしなければならないことは、開発者にとって大きな悩みの種でした。

getGT() と useGT() は、一般的な i18n パターンに従っています。

export default function Page() {
  const gt = useGT()
  // const gt = await getGT(); サーバーサイドの場合

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

他の i18n ライブラリに合わせるため、gt() は意図的に同期のままにしていました。 そのデメリットは、2 段階の翻訳プロセス が必要になることでした。

1. API にテキストを登録する。 2. 翻訳結果を表示するには、2 回目のレンダリングを待つ必要がある。

現在は、コンパイラのおかげで、翻訳可能なコンテンツが事前にスキャンされ、コンパイル時に useGT() または getGT() に直接渡されます。 つまり、翻訳は runtime ですぐに利用でき、ページを再読み込みする必要はありません。

ビルド時のLint

これまでは、<T> コンポーネントの誤った使い方を検出するには、カスタムリンター付きで gtx-cli を実行する必要がありました。 そのため、開発 時と 本番 時で挙動に不一致が生じていました。

6.2.0 では、Lint ルールが SWC プラグイン内で直接適用されるようになりました。 翻訳対象のコンテンツが <T> コンポーネントで囲まれていない場合は、ビルド時エラー が発生するため、問題を早い段階で検出できます。

なぜ SWC なのか (今のところ) ？

runtime からビルド時への移行は、まだ始まったばかりです。 まずは Next.js から対応を始めていますが、近いうちに他のフレームワークもサポートする予定です。 同じ機能を提供する Babel プラグインも、すでにロードマップに入っています。

gt-next 6.2.0 は、より高速で信頼性の高い翻訳ワークフローの土台を築くものです。 ロジックをビルド時に移すことで、runtime の複雑さを減らしつつ、翻訳をより即時かつ予測しやすいものにしています。