feat(i18n): adopt next/root-params - #9105
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
|
||
| // Gets the current full pathname for a given path | ||
| const [locale, pathname] = basePage.getLocaleAndPath(path, routeLocale); | ||
| const [locale, pathname] = await basePage.getLocaleAndPath(path); |
There was a problem hiding this comment.
No need to pass the routeLocale anymore since we can read from next/root-params within getLocaleAndPath.
| const RootLayout: FC<RootLayoutProps> = async ({ children, params }) => { | ||
| const { locale } = await params; | ||
| const RootLayout: FC<PropsWithChildren> = async ({ children }) => { | ||
| const locale = await getLocale(); |
There was a problem hiding this comment.
Using await getLocale() returns the returned locale from i18n.tsx—including potential defaults.
| export default getRequestConfig(async params => { | ||
| // An explicit locale passed to an awaitable API like `getTranslations({ locale })` | ||
| // wins, otherwise we read the `[locale]` segment of the root layout | ||
| let locale = params.locale ?? (await getRootLocale()); |
There was a problem hiding this comment.
This is the key: requestLocale is no longer needed, but we can read from next/root-params.
I've kept the behavior to read an override from a call site though, as this can be handy for Server Actions and Route Handlers (where next/root-params is not yet supported).
| // Forces the current locale to be the Default Locale | ||
| setRequestLocale(defaultLocale.code); | ||
| export const getLocaleAndPath = async (path = []) => { | ||
| const locale = (await getRootLocale()) ?? defaultLocale.code; |
There was a problem hiding this comment.
I've considered reading from await getLocale() here, but that would internally apply defaults. Might be safer to keep an additional call to next/root-params here so the validation below continues to work as-is.
| } | ||
|
|
||
| // Configures the current Locale to be the given Locale of the Request | ||
| setRequestLocale(locale); |
32f79c9 to
a3cfe02
Compare
next/root-params
|
@ovflowd @AugustinMauroy I thought you might be interested in adopting On a related note, I've been working on a new tool called |
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #9105 +/- ##
==========================================
+ Coverage 86.01% 86.13% +0.12%
==========================================
Files 86 86
Lines 6099 6051 -48
Branches 358 357 -1
==========================================
- Hits 5246 5212 -34
+ Misses 849 835 -14
Partials 4 4 ☔ View full report in Codecov by Harness. |
Next.js 16.3 exposes the `[locale]` root segment to Server Components via `next/root-params`, which next-intl reads directly as of 4.13. That removes the `setRequestLocale` bookkeeping the app needed for static rendering, along with the locale threading through every page's `params`. - `i18n.tsx` resolves the locale from the root param, so `requestLocale` is no longer needed. An explicit locale passed by a call site still wins, which stays useful for Server Actions and Route Handlers, where `next/root-params` is not supported yet - the root layout reads the locale via `getLocale()`, which returns the already validated value from `i18n.tsx`, and no longer receives `params` - `generateMetadata` and `getLocaleAndPath` read `next/root-params` directly rather than `getLocale()`, because they need the raw segment: `getLocale()` returns the already defaulted value, which would change the metadata emitted for unknown and disabled locales and make the notFound/redirect validation in `getLocaleAndPath` unreachable
📦 Build Size ComparisonSummary
|
a3cfe02 to
7bcaf09
Compare
Done! |
AugustinMauroy
left a comment
There was a problem hiding this comment.
LGTM that make thing cleaner
Description
Next.js 16.3 ships with
next/root-params, which is a significant improvement for users ofnext-intl.See the introductory blog post: Using next/root-params in Next.js 16.3
I went ahead to see how this integrates with nodejs.org, and it seems to work well!
Validation
I checked various languages and also different 404 states.
Related Issues
None.
Check List
pnpm formatto ensure the code follows the style guide.pnpm testto check if all tests are passing.pnpm buildto check if the website builds without errors.