Do I need a middleware? #781
Replies: 1 comment 2 replies
-
Hey, thanks for the kind words and for the curious question! :)
Which section in the docs are you referencing here? There's a section on the Next.js static export feature, mentioning usage without a middleware: Usage without middleware (static export).
If you resolve the locale in a layout, it will require that your app only works with dynamic rendering—that also affects costs.
Absolutely is, I'd really like to refactor the code at some point, potentially breaking the responsibilities into clearer defined code paths! The middleware has a pretty good test suite that could help with such a refactor. The middleware currently has these responsibilities:
(hope I've got all) Note that users can also implement a custom middleware if that suits the use case better. |
Beta Was this translation helpful? Give feedback.
-
Hey folks, hey @amannn thanks again for making this awesome package.
According to the docs, if we wish to skip on using middleware, we should use another package. I believe this isn't correct, but I'd love to hear why I'm wrong and learn from it. I understand that the middleware is more complex than I show here (https://github.com/amannn/next-intl/blob/main/packages/next-intl/src/middleware/middleware.tsx) but I think it is more complex due to all the "extra stuff" and I'd like to propose an alternative, simpler usage.
The way I see it, middleware performs 4 distinct actions (from the perspective of the user):
A lot of projects don't use 3 and 4. In fact, even though it seems like a cool idea, it is generally a poor UX and SEO practice to do forcible redirects, and is used only when we legally must redirect users like that, and even then it is done based on geofencing. When it comes to asking users to change market or language, that is best done as a popup in a client component and has nothing to do with next-intl. My point - a lot of projects don't need 3 & 4 AND 3 & 4 make up for the majority of the complexity of middleware.
Which leaves us with a middleware that only performs numbers 1 & 2. There is nothing in them that I can see, that requires them to be in the middleware:
resolveLocale
and used by the middleware to chew up the request and config, and spew out a validated locale.NextIntlClientProvider
,unstable_setRequestLocale
and the request assignment that the middleware currently does.So, where am I going with this? I'm not saying remove middleware, a lot of people want it. But what if people like me were to drop the middleware entirely (thus reducing costs) and in our layouts write something along the lines of:
const {_, locale} = resolveLocale(request);
<NextIntlClientProvider locale={locale} />
The first one is self explanatory, it would put the decisionmaking logic closer to us. The second one would have
next-intl
decide which environment we are in at the moment (i believe you do that by forking package paths at the moment), and choose if the locale goes intounstable_setRequestLocale
or into a Request+Context.Where am I wrong? :D
Beta Was this translation helpful? Give feedback.
All reactions