Doesn't support static/SSG outputs

[manhthepixta]

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.

[isaachinman]

Did you try?

[manhthepixta]

Did you try?

Sorry what do you mean 😄 ?
This is the warning console

[isaachinman]

Did you try putting the decorator on just the pages you want?

[manhthepixta]

Did you try putting the decorator on just the pages you want?

Oh I don't know I can do that.
Currently I'm putting this decorator @withTranslation('translations') on each page.
So do you mean I can use @appWithTranslation instead?

[janus-reith]

I doubt this will work.
The@appWithTranslation HOC relies on getInitialProps and uses this to destrcuture the request from context:
const { req } = ctx.ctx

ctx nested in ctx is present on getInitalProps for the _app page, while on other pages it is just ctx.req.

[isaachinman]

Related to #544. Could investigate moving this to a static or similar.

[janus-reith]

For reference: https://github.com/vinissimus/next-translate allows static pages, although, there seems to be a pre-build step creating pages from a separate pages_ folder - Not really an approach I'm happy with, but it could still be interesting to investigate the approach here.

Maybe the recently introduced getStaticProps could work for this usecase.

[ckeeney]

I don't actually know if it's possible to support automatic static optimization with this library. I don't believe getStaticProps will 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 getInitialProps into 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".

[janus-reith]

@ckeeney I meant to use getStaticProps to fetch the translations, so we don't have to do any preprocessing steps like next-translate currently does, not to determine the requested language. But maybe that won't be necessary if they are available locally.

And yes, for the latter a middleware on the server is probably better than a HOC, or whatever comes out of the approach the nextjs team is taking with customized routes currently, although this still is a bit blurry for me. Agreed, next-i18next currently is not suitable for that / not sure how much of its current functionality could be kept for that.

[isaachinman]

I don't actually know if it's possible to support automatic static optimization with this library

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 getStaticProps will indeed be useful.

However this library still seems to work without the middleware

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.

[pier-verdu]

@isaachinman do you think that NextJS 9.3 can help?
Thanks

[isaachinman]

@Pierre-CLIND We could indeed most likely migrate from getInitialProps to getStaticProps, however we are no closer to being able to get rid of a custom server.

[lleonesouza]

new updates on?
In dev env it's works, but in productions it's break
anyone knows how can I avoid it?

[martpie]

The warning is (most probably) not responsible of this error. Check your logs server-side.

[AndyOGo]

I have the same warning, it's caused by the HoC appWithTranslation is adding getInitialProps()...

Here is the next.js documentation about it:
https://github.com/zeit/next.js/blob/master/errors/opt-out-auto-static-optimization.md

[7iomka]

@AndyOGo that happens because we use in _app getInitialProps
How next.js docs (https://nextjs.org/docs/advanced-features/custom-app)
say:

Only uncomment this method if you have blocking data requirements for
// every single page in your application. This disables the ability to
// perform automatic static optimization, causing every page in your app to
// be server-side rendered.
// MyApp.getInitialProps = async (appContext) => {
// // calls page's getInitialProps and fills appProps.pageProps
// const appProps = await App.getInitialProps(appContext);
//
// return { ...appProps }
// }

Any news to avoid use getInitialProps in _app?
Please!

[martpie]

There is no way around it for now. A lot of Next.js plugins rely on extending _app's getInitialProps unfortunately, and next-i18next is one of them.

IMHO, static optimization is a small loss compared to the benefits next-i18next brings.

[Geoff-Ford]

@Pierre-CLIND We could indeed most likely migrate from getInitialProps to getStaticProps, however we are no closer to being able to get rid of a custom server.

Now that the custom server problem is sorted, will the potential switch to getStaticProps be considered? I value the static optimization so this is my only remaining blocker to using this plugin.

[isaachinman]

@Geoff-Ford Being able to support static/SSG output is an entirely different proposition. The next-i18next package (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.

[Geoff-Ford]

Thanks for that. Yes, this is what I was also thinking. Being able to statically generate pages with localeSubpaths would 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.

[isaachinman]

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.

[nfantone]

@Geoff-Ford

Any dynamic content that required SEO would have to go via a lambda anyway so could include language detection.

Not necessarily. You can statically generate your sites and fetch data at build-time and/or return revalidate: true from getStaticProps to keep your dynamic bits up-to-date. No (extra) lambdas required.

[nfantone]

@isaachinman

The next-i18next package (and indeed any full-featured i18n package) has a server runtime dependency to do things like check cookies, perform redirects, bundle necessary resources, etc.

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 getStaticProps ahead of time.

[isaachinman]

@nfantone Sure:

1. Yes, we use i18next-http-middleware for detection. Cookies, headers, etc, are handled. The proportion of users who want to handle redirects at some other layer (nginx/CDN) is much smaller than those who want a solution to "just work". Note that this functionality comes from the i18next ecosystem, not next-i18next.

2. We are redirected based on runtime user values. We definitely do need a middleware to achieve that. Client side redirects are unacceptable for most setups.

3. Yup, this can be ignored.

Server side language detection and redirection are the main sticking points that keep this project from supporting SSG.

[nfantone]

@isaachinman Thanks for the clarification above. If I may, let me rehash some of my previous comments based on yours.

1. Check cookies. Again - this I see as a self-imposed problem. The fact that server side detection is a feature that comes from the upstream library do bring forward some further restrictions (and, up to a certain point, it'd make sense for next-i18next to have feature parity). But there are so many different ways to achieve this, including options that do not require a server at all, that it'd make absolute sense to me to leave this up to users. Move it to a separate module away from core, easing constraints and paving the way for other, arguably more important features, such as SSG. Let users chose which setup fits their needs.

The proportion of users who want to handle redirects at some other layer (nginx/CDN) is much smaller than those who want a solution to "just work".

Mind sharing the source of that? What's that proportion exactly? Incidentally, nginx/CDN/AWS/etc. solutions also "just work".

2. Perform redirects. Why redirect at all, in the first place? What values are needed? Why do this at a library level?

Client side redirects are unacceptable for most setups.

Which setups are you referring to here, exactly? I might be the odd one out, but most of the setups I enjoy working on and developing would happily accept client-redirects, as a trade-off, if it'd bring benefits to the table.

[isaachinman]

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.

[SalahAdDin]

@isaachinman When? when will be these changes?

[pier-verdu]

@SalahAdDin Everything is here:
vercel/next.js#17078

[isaachinman]

The timeline is entirely dictated by the Vercel team. Please read through the RFC for the latest updates.

[Geoff-Ford]

A good chunk of i18n work has just been released!!:

https://github.com/vercel/next.js/releases/tag/v10.0.0

[SalahAdDin]

Oh s***, here we go again.

[Geoff-Ford]

Nah, this was just an update for anyone following this now old thread that the core library have indeed released i18n built in, albeit just the beginnings.

[isaachinman]

Please follow #869 for updates!

[isaachinman]

Fixed in next-i18next@8.0.0.