You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using this thread to collect aspects about the current next-intl middleware that we could potentially address in case a revamp is relevant after the Next.js change.
Maybe opting out of root-redirect? Possibly already by adapting the matcher, but would there be an advantage to make this more explicit?
Should the middleware automatically decide if a request should be handled or not (see example from docs), allowing us to remove the default matcher? (might need an option to opt-out) We'd only be able to do it for the localePrefix: 'always' case though (and only if the user doesn't want to automatically redirect /users → /en/users). Is this helpful?
We can make these changes in any case, but in case a refactoring is necessary after the Next.js change, maybe it'd be worth waiting a bit.
The text was updated successfully, but these errors were encountered:
As far as I understand the feature, it's mostly targeted at validation. The best I can think of is a validation that the [locale] param contains a valid value and alternatively call notFound(). This would be a slight improvement, but if the mere presence of an interceptor opts the page into dynamic rendering, this already has a downside in comparison to running the validation in [locale]/layout.tsx.
From a first glance, the new interceptors feature currently doesn't look like it could help with the pain points that were mentioned above. I'll keep an eye on it though.
Is your feature request related to a problem? Please describe.
It seems like there's work happening on the Next.js side on a middleware revamp: vercel/next.js#46722 (comment)
I'm using this thread to collect aspects about the current
next-intl
middleware that we could potentially address in case a revamp is relevant after the Next.js change.Describe the solution you'd like
My personal wishlist for Next.js:
locale
to the rendering phase (see Reading params deeply in Server Components (e.g. for i18n / multi-tenancy) vercel/next.js#58862). Ideally this would be possible without a middleware in the first place though.Mentioned both here.
Separately from this, there are some use cases we could support better that do not rely on Next.js:
We can make these changes in any case, but in case a refactoring is necessary after the Next.js change, maybe it'd be worth waiting a bit.
The text was updated successfully, but these errors were encountered: