Обзор

В gt-next 6.2.0 мы сделали большой шаг к переносу обработки из времени выполнения на этап сборки с помощью плагина SWC. Такой подход открывает новые возможности: хеширование на этапе компиляции, предварительно сгенерированные переводы и более строгую валидацию — и всё это без дополнительных накладных расходов во время выполнения.

Чтобы не распыляться, мы начали с трёх ключевых улучшений.

• Хеширование на этапе компиляции
• Перевод по запросу
• Правила линтинга на этапе сборки

Хеширование на этапе компиляции

Хотя это сравнительно небольшая оптимизация, теперь мы выполняем вычисление хешей на этапе сборки, а не во время выполнения. Функциям вроде 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')}
    </>
  )
}

Мы намеренно оставили gt() синхронным, чтобы он соответствовал другим библиотекам i18n. Обратной стороной был двухэтапный процесс перевода:

1. Зарегистрировать текст через API. 2. Дождаться второго рендера, чтобы отобразить переведённый текст.

Теперь, благодаря компилятору, контент для перевода заранее сканируется и напрямую передаётся в useGT() или getGT() на этапе компиляции. Это значит, что переводы доступны сразу во время выполнения — без перезагрузки страницы.

Линтинг на этапе сборки

Раньше для обнаружения некорректного использования компонентов <T> нужно было запускать gtx-cli с пользовательским линтером. Из-за этого возникали расхождения между поведением в режиме разработки и production.

Начиная с версии 6.2.0, правила линтинга применяются непосредственно в плагине SWC. Если какой-либо переводимый контент не обёрнут в компонент <T>, вы получите ошибку на этапе сборки, что позволит выявить проблему заранее.

Почему SWC (пока)?

Наш переход от времени выполнения к подходу на этапе сборки пока ещё на раннем этапе. Мы начинаем с Next.js, но вскоре планируем поддержать и другие фреймворки. Плагины Babel с той же функциональностью уже есть в планах.

gt-next 6.2.0 закладывает основу для более быстрого и надёжного процесса перевода. Перенося логику на этап сборки, мы уменьшаем сложность времени выполнения и делаем переводы более быстрыми и предсказуемыми.