Skip to content
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

Draft
wants to merge 38 commits into
base: v4
Choose a base branch
from
Draft

Conversation

amannn
Copy link
Owner

@amannn amannn commented Nov 11, 2024

An exploration of how next-intl can adapt better for ppr, dynamicIO and rootParams (see #1493).

Centralized validation of [locale] segment with dynamicParams = 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:

  1. Currently, providing locales statically is a bit cumbersome, so this would definitely rely on 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.
  2. dynamicParams is not compatible with dynamicIO—and maybe never will:
"dynamicParams" is not compatible with `nextConfig.experimental.dynamicIO`. Please remove it.

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 for rootParams to get rid of this API.

Reading the locale param without suspending

Currently 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(…) and await

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 and usePathname 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

  1. For a setup with i18n routing there are too many pieces missing currently
  2. For a setup without i18n routing ppr and dynamicIO might work (but requires feat!: Remove default of now={new Date()} from NextIntlClientProvider for usage with format.relativeTime (preparation for dynamicIO) #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:

  1. Adapt docs
    1. Read from rootParams in i18n/request.ts.
    2. Use getLocale() instead of reading from params in components. This can be strongly-typed and potentially overridden.
    3. 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.
    4. Clarify the job of the middleware (see docs for matcher)
  2. Release minor version
    1. Re-introduce ({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 to getRequestConfig but not read.
    2. We don't rely anymore on the hardcoded [locale] segment and also don't need to bump the peer dependency aggressively once this API is introduced since next-intl doesn't read from it.
    3. Deprecate await requestLocale once rootParams 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 supports rootParams—therefore don't deprecate too aggressively.
    4. Deprecate setRequestLocale

Copy link

vercel bot commented Nov 11, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
next-intl-docs ✅ Ready (Inspect) Visit Preview 💬 Add feedback Nov 19, 2024 11:25am
next-intl-example-app-router ❌ Failed (Inspect) Nov 19, 2024 11:25am
next-intl-example-app-router-without-i18n-routing ✅ Ready (Inspect) Visit Preview 💬 Add feedback Nov 19, 2024 11:25am

@amannn amannn changed the title experiment: PPR & friends feat: PPR & friends Nov 11, 2024
@amannn amannn changed the base branch from v4 to feat/dio-now November 12, 2024 14:29
@amannn amannn changed the title feat: ppr, dynamicIO & friends feat: Exploration of ppr, dynamicIO & friends Nov 13, 2024
# 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>
Copy link
Owner Author

@amannn amannn Nov 14, 2024

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.

: routing.defaultLocale;

return {
locale,
messages: (await import(`../../messages/${locale}.json`)).default
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: Revert

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant