-
-
Notifications
You must be signed in to change notification settings - Fork 236
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Exploration of ppr
, dynamicIO
and rootParams
#1531
base: v4
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
…ply, static messages import
ppr
, dynamicIO
& friendsppr
, dynamicIO
& friends
# Conflicts: # docs/src/pages/docs/usage/configuration.mdx # docs/src/pages/docs/usage/dates-times.mdx # examples/example-app-router-playground/src/i18n/request.tsx # packages/next-intl/eslint.config.mjs # packages/next-intl/src/server/react-server/getDefaultNow.tsx
<Navigation /> | ||
{children} | ||
</NextIntlClientProvider> | ||
<Suspense> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should ideally work without this (probably requires an equivalent of dynamicParams = false
.
ppr
and dynamicIO
ppr
, dynamicIO
and rootParams
: routing.defaultLocale; | ||
|
||
return { | ||
locale, | ||
messages: (await import(`../../messages/${locale}.json`)).default |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO: Revert
An exploration of how
next-intl
can adapt better forppr
,dynamicIO
androotParams
(see #1493).Centralized validation of
[locale]
segment withdynamicParams = false
If params can be read statically, we could use
dynamicParams = false
to return a 404 for unknown locales (see d1a0308).However, it seems like this isn't a good idea to introduce yet:
rootParams
. If that's the case, this could simplify the usage for the common case, but maybe we need to cover the case for unknown locales earlier in the docs.dynamicParams
is not compatible withdynamicIO
—and maybe never will:However, it seems like Next.js is working on an alternative to
dynamicParams = false
. With this, maybe we'll have a reasonable solution for centralized validation of the[locale]
segment.Usage of
setRequestLocale
Calling
setRequestLocale
within a'use cache'
boundary doesn't seem to work. We need to wait forrootParams
to get rid of this API.Reading the
locale
param without suspendingCurrently not easily possible, waiting for an alternative to
dynamicParams = false
: vercel/next.js#71927.What did work in my test though is to use
'use cache'
on both the layout and page entry point. This might not fit your application though and furthermore makes it impossible to read request-specific params in components. EDIT: It only works in dev, not when building the app.Another use case to be tested would be mixing a statically known
[locale]
param with a dynamic child page (see https://nextjs.org/blog/our-journey-with-caching#partial).Importing of JSON messages
Dynamic imports currently cause an error: vercel/next.js#72589.
Effect of
use(…)
andawait
For the APIs that
next-intl
offers, these seem to not require a suspense boundary for async data—that's helpful.Effect of client-side hooks on caching
Hooks like
useParams
,useSelectedLayoutSegment
andusePathname
work fine in development but error out during the build when used in a dynamic segment like[locale]
, asking for a suspense boundary or'use cache'
. Not sure what the expected behavior is, but there's definitely an inconsistency here. See vercel/next.js#72756.EDIT: This would probably also require a replacement for
dynamicParams = false
.Conclusion
ppr
anddynamicIO
might work (but requires feat!: Remove default ofnow={new Date()}
fromNextIntlClientProvider
for usage withformat.relativeTime
(preparation fordynamicIO
) #1536)However, it seems like with #1412 users can adopt these modes without any changes necessary in
next-intl
.Once
rootParams
is a thing, we can:rootParams
ini18n/request.ts
.getLocale()
instead of reading from params in components. This can be strongly-typed and potentially overridden.getTranslations({locale: …})
should only be relevant for overriding locales, not for enabling static rendering. We might want to re-introduce a sync({locale})
arg for this use case though.({locale})
for overriding a locale (this is now only an edge case for apps that render with multiple locales simultaneously on the server). Also: Warn if({locale})
is passed togetRequestConfig
but not read.[locale]
segment and also don't need to bump the peer dependency aggressively once this API is introduced sincenext-intl
doesn't read from it.await requestLocale
oncerootParams
is stable and supported for some time. Consider that users on older Next.js versions will still rely on this until they've upgraded to a Next.js version that supportsrootParams
—therefore don't deprecate too aggressively.setRequestLocale