next-i18next: Doesn't support static/SSG outputs
I get this error after building: You have opted-out of Automatic Static Optimization due to getInitialProps in pages/_app.
My _app.js file:
import React from 'react';
import App from 'next/app';
import Head from 'next/head';
import { Provider } from 'react-redux';
import { store } from 'store';
import { appWithTranslation } from '../i18n';
@appWithTranslation
class MyApp extends App {
render() {
const { Component, pageProps } = this.props;
return (
<Provider store={store}>
<Component {...pageProps} />
</Provider>
);
}
}
export default MyApp;
I know appWithTranslation HOC contains getInitialProps so that warning appears. Is there anyway to use it on each page individually but not the pages/_app.js?
Thanks.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 15
- Comments: 34 (12 by maintainers)
Currently, it is not. It will be possible with the upcoming NextJs plugin setup, assuming we also get middlewares support on view routes. Something like
getStaticPropswill indeed be useful.No, it does not. The middleware is absolutely crucial for server side language detection, amongst other things.
Basically: this package will be rewritten once plugin support drops, and should at that point in time support static and serverless deployments. We can’t really clarify anything until the plugin API solidifies.
Please follow https://github.com/isaachinman/next-i18next/issues/869 for updates!
Thanks for that. Yes, this is what I was also thinking. Being able to statically generate pages with
localeSubpathswould cover most of my cases. If a user arrives directly to a specific page with a specific locale, then I would be happy to assume that is the required language. Any dynamic content that required SEO would have to go via a lambda anyway so could include language detection. That just leaves traffic arriving to the home page where I would need to create a lambda to detect language and redirect to the preferred locale variant.Hi @nfantone. Checking cookies and performing redirects are definitely both features required by the majority of users. Some exciting stuff is coming from the Vercel team via the Next core directly, which may end up making this package unnecessary, and will still support cookies, redirects, and SSG.
Yeah that’s loosely correct, @Geoff-Ford. I have been kicking around ideas of how to support this, and it’s on my list (after a few other more pressing matters). If you’d like to help, and/or discuss implementation, feel free to email me directly.
A good chunk of i18n work has just been released!!:
https://github.com/vercel/next.js/releases/tag/v10.0.0
@Geoff-Ford Being able to support static/SSG output is an entirely different proposition. The
next-i18nextpackage (and indeed any full-featured i18n package) has a server runtime dependency to do things like check cookies, perform redirects, bundle necessary resources, etc.If you were willing to completely drop cookie/redirect functionality, it would be possible to support static/SSG outputs. This is something I’ve been exploring recently, but do not have any concrete updates on.
Now that the custom server problem is sorted, will the potential switch to
getStaticPropsbe considered? I value the static optimization so this is my only remaining blocker to using this plugin.new updates on? In dev env it’s works, but in productions it’s break anyone knows how can I avoid it?
Fixed in
next-i18next@8.0.0.@isaachinman
Excuse my ignorance, but I’m not quite following you here. Would you mind elaborating on why a server component is needed?
Check cookies. What for exactly? Language detection? I could argue this is not something a i18n library should worry about. At least, not as a core feature. Might as well exist in user-land entirely. I could, say, detect user’s language through a header and redirect via a proxy on my own infrastructure. Storing the language preference can also be done independently of cookies.
Perform redirects. Support for redirects has landed on Next.js since 9.5. No need for a custom server or server middleware no pull that off. Plus, you could always “redirect” client-side. (Edit: I noticed there’s been some work on this regard already 👍).
Bundle necessary resources. Not sure what this means in the context, to be honest. You mean parse and modify translation files in some way? Do we need a request? If not, this can also be achieved using SSG on
getStaticPropsahead of time.There is no way around it for now. A lot of Next.js plugins rely on extending
_app’sgetInitialPropsunfortunately, andnext-i18nextis one of them.IMHO, static optimization is a small loss compared to the benefits
next-i18nextbrings.I don’t actually know if it’s possible to support automatic static optimization with this library. I don’t believe
getStaticPropswill have access to the request object, and the request object is required to determine preferred language.Maybe it’s possible to move all the logic from
getInitialPropsinto the middleware where the request is obviously available. However this library still seems to work without the middleware (I think probably some features don’t work, but it’s still usable). I imagine this would no longer be the case if we go this route. This is relevant to me because I had trouble getting the middleware wired up when deploying a nextjs project as a Google Firebase function, but it still “worked okay”.