Назад

gt-react@11.0.0

Ernest McCarter avatarErnest McCarter
gt-reactgt-nextgt-react-nativegt-tanstack-starti18nperformance

Обзор

gt-react 11 — центральный элемент согласованного релиза General Translation для наших React-библиотек. gt-react, gt-next, @generaltranslation/react-core, gt-react-native и gt-tanstack-start перешли на версию 11 вместе с gt-i18n 1.0 и generaltranslation 9.0.

У этого релиза было две цели: упростить расширение runtime i18n на большее число фреймворков и сократить объем кода General Translation, поставляемого пользователям. В результате появилась общая основа с более понятными процессами настройки для приложений, работающих только в браузере, и приложений с серверным рендерингом.

Полноценная поддержка Pages Router

Самое заметное для пользователей изменение в v11 — прямая поддержка Next.js Pages Router в gt-next. Раньше приложения с Pages Router должны были использовать gt-react. Теперь они могут использовать withGTServerSideProps(), чтобы загружать локаль и снимок переводов, а затем передавать их в <GTProvider> в _app.tsx.

В v11 также добавлены маршрутизация по локалям на основе middleware и withGTStaticProps() для статической генерации.

Обновленные сценарии настройки

  • React SPAs - Инициализируйте gt-react с помощью initializeGTSPA() до загрузки приложения. Инициализатор заранее определяет локаль и переводы, поэтому для SPA провайдер больше не нужен. См. Быстрый старт SPA для React.
  • React с серверным рендерингом - Один раз инициализируйте runtime, затем определите локаль запроса и снимок переводов на сервере. Передайте и locale, и translations в <GTProvider> для синхронной гидратации. См. Быстрый старт для React с серверным рендерингом.
  • TanStack Start - Определите локаль и снимок переводов в корневом загрузчике, затем передайте их в <GTProvider>. Выбор локали также сохраняется через настроенный cookie-файл локали. См. Быстрый старт для TanStack Start.

Более компактный и расширяемый runtime

В версии 11 удалён код, который не нужен клиентским приложениям, а пакеты стало проще оптимизировать для tree-shaking в бандлерах. Код, связанный с переводом и используемый только при разработке, также можно исключить из production-сборок.

В нашем бенчмарке production-сборки Next.js объём клиентского JavaScript, приходящегося на GT, сократился примерно с 251 КБ до 108 КБ: снижение на 57,1%. Здесь измеряется часть клиентского бандла, относящаяся к General Translation, а не весь бандл приложения. Изучите данные по пакетам и точкам входа в Odysseus Bundle Size Tracker.

Этот же рефакторинг даёт нам общую основу для поддержки большего количества фреймворков.

Что дальше

Мы планируем и дальше уменьшать клиентский бандл. Следующий шаг — сделать такие возможности, как перевод словарей и горячая перезагрузка при разработке, модульными, чтобы приложения включали только те функции, которые действительно используют.

Мы также планируем в большей степени опираться на архитектуру, управляемую компилятором. Перенос большего объема работы на этап сборки, а не в runtime, должен уменьшить объем клиентского JavaScript и накладные расходы runtime, а также упростить поддержку большего числа фреймворков.

Ссылки