feat: Exploration of `ppr` and `dynamicIO`

An exploration of how next-intl can adapt better for ppr and dynamicIO (see https://github.com/amannn/next-intl/issues/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 https://github.com/amannn/next-intl/commit/d1a0308e72d7f5111a7dcc6f34efd22d8ad0e576).

However, it seems like this isn't a good idea to introduce yet:

Currently, providing locales statically is a bit cumbersome, so this would definitely rely on a mechanism from Next.js to read params deeply. 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 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 a mechanism from Next.js to read params deeply to get rid of this API.

Reading the `locale` param without suspending

Currently not easily possible, waiting for an alternative to dynamicParams = false: https://github.com/vercel/next.js/discussions/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: https://github.com/vercel/next.js/issues/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 https://github.com/vercel/next.js/issues/72756.

EDIT: This would probably also require a replacement for dynamicParams = false.

Conclusion

For a setup with i18n routing there are too many pieces missing currently
For a setup without i18n routing ppr and dynamicIO might work (but requires https://github.com/amannn/next-intl/pull/1536)

API considerations for next-intl to consider in the future:

In case an API gets added for reading params deeply we should let the user read from it by themselves in i18n/request.ts. This way we can avoid hardcoding the [locale] segment and also don't need to bump the peer dependency aggressively once this API is introduced.
Should we warn when getLocale is called in i18n/request.ts? Would require AsyncLocalStorage.
Should we adapt the getting started guide to match the middleware only on /? This will be possible once reading params deeply is a thing.

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

amannn / next-intl