Back

gt-react@11.0.0

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

Overview

gt-react 11 is at the centre of a coordinated General Translation release across our React libraries. gt-react, gt-next, @generaltranslation/react-core, gt-react-native, and gt-tanstack-start all moved to version 11, alongside gt-i18n 1.0 and generaltranslation 9.0.

This release had two goals: make the i18n runtime easier to extend to more frameworks and reduce the amount of General Translation code shipped to users. The result is a shared foundation with clearer setup flows for browser-only and server-rendered apps.

First-class Pages Router support

The biggest user-facing change in v11 is direct support for the Next.js Pages Router in gt-next. Previously, Pages Router apps had to use gt-react. They can now use withGTServerSideProps() to load the locale and translation snapshot, then pass both to <GTProvider> in _app.tsx.

The v11 release line also adds middleware-based locale routing and withGTStaticProps() for static generation.

Updated setup flows

  • React SPAs - Initialise gt-react with initializeGTSPA() before the app loads. The initialiser resolves the locale and translations beforehand, so SPAs no longer need a provider. See the React SPA Quickstart.
  • Server-rendered React - Initialise the runtime once, then resolve the request locale and translation snapshot on the server. Pass both locale and translations to <GTProvider> for synchronous hydration. See the server-rendered React Quickstart.
  • TanStack Start - Resolve the locale and translation snapshot in the root loader, then pass both to <GTProvider>. Locale selection also persists through the configured locale cookie. See the TanStack Start Quickstart.

A smaller, more extensible runtime

Version 11 removes code that client apps do not need and makes the packages easier for bundlers to tree-shake. Development-only translation paths can also be dropped from production builds.

In our production Next.js benchmark, GT-attributed client JavaScript fell from about 251 KB to 108 KB: a 57.1% decrease. This measures the General Translation portion of the client bundle, not the entire application bundle. Explore the package and entry-point data in the Odysseus Bundle Size Tracker.

The same refactor gives us a common foundation for supporting more frameworks.

Looking ahead

We plan to keep reducing the client bundle. Next, we want to modularise features such as dictionary translation and development hot reload so apps only ship the features they use.

We also plan to rely more heavily on a compiler-driven architecture. Moving more work to build time instead of runtime should reduce client JavaScript and runtime overhead, while making it easier to support more frameworks.