Support for getInitialProps

[timothyhague]

Next.js only recommends the use of getStaticProps and getServerSideProps, due to it allowing for static page generation (if that is something you want). It doesn't say that getInitialProps is no longer something you should use, nor that they plan to make it obsolete. In my case, and the case for many others, it makes better sense to continue using getInitialProps.

Would you consider returning support for getInitialProps?

https://nextjs.org/docs/api-reference/data-fetching/getInitialProps

[isaachinman]

What use case would necessitate getInitialProps that couldn't be solved with getServerSideProps?

[timothyhague]

The main issue we have is that, using getServerSideProps means a request to the server is made on every page transition in the client. So, rather than getInitialProps running and making a direct request to an api from the client, a request is made to the node server, which runs the getServerSideProps function, which only then makes a request to the api and waits/returns the response.

We could explore a refactor to try to bypass both getServerSideProps and getInitialProps, but the only reason we currently have to do that, is to keep current with this so far perfect for us i18n package.

Changing to a different i18n package which supports getInitialProps is a consideration, so as not to bother you with this :) However, I've not yet found another which supports the i18next format, which also works well with Next.js.

[isaachinman]

The main issue we have is that, using getServerSideProps means a request to the server is made on every page transition in the client

Why not use shallow routing? I'm not convinced that your specific use case necessitates getInitialProps.

That said, all that serverSideTranslations does is return an internally-used object within the page's props. You can see consumption of that object here.

Basically, it should be extremely trivial to use serverSideTranslations with getInitialProps. It probably works already with some fiddling, and if not, it would make for a very simple PR. Feel free to contribute!

[timothyhague]

Fair enough, agree, we could look at refactoring to bypass both getServerSideProps and getInitialProps, but our codebase is of a size where that wouldn't be a small task. We're finely tuned to optimise page transitions around getInitialProps.

I'll look in to this option you suggest, looks like a good one. Thanks a lot for the response 👍

[isaachinman]

Let me know if I can offer any further guidance!

[slava-lu]

So it does not support getInitialProps?

getServerSideProps works bad with redux and is user - unfriendly for redux apps.
With redux you need your actions to be dispatched in the browser, not on the server to provide loading information and not to create each redux store on every request and than painfully hydrate it with the client state.

[isaachinman]

@slava-lu We have clearly discussed the issue above. If you can use serverSideTranslations to pass pageProps via getInitialProps, it will work with next-i18next.

[isaachinman]

Did a little more digging on this today. Apologies, I misspoke at first – I forgot that getInitialProps runs isomorphically, and serverSideTranslations relies on server side modules like fs – the whole point is that it loads translations from your filesystem.

Supporting getInitialProps again will not work without reinventing a lot of the isomorphic support that next-i18next used to have. It involves using i18next-fs-backend if you're in a server context, or i18next-http-backend if you're in a browser context.

This is not something planned for future versions of next-i18next. The aim of this package is to becoming increasingly simple, as NextJs pulls this functionality in with first-class support.

If your use case involves using getInitialProps, I would suggest downgrading to next-i18next <v8 until you can refactor.

Let me know if I can help any further.

[DonovanCharpin]

There are ongoing discussions like this one about getServerSideProps not really replacing getInitialProps. It means that a lot of projects are still running with getInitialProps and unfortunately cannot upgrade next-i18next since 7.0.1. I think choosing not to support getInitialProps while this is not deprecated by nextjs is a mistake. We tried to migrate a big nextjs project but the result was not really good with the recommended methods yet, we had to rollback.

I would love to find a way to keep getInitialProps (that works great for many use cases) and be able to upgrade this awesome library that provide +10k translations for our website in multiple languages!

[slava-lu]

@DonovanCharpin I have moved to https://github.com/vinissimus/next-translate
It seems to seamlessly supports all the methods.

[isaachinman]

I think choosing not to support getInitialProps while this is not deprecated by nextjs is a mistake

To be clear, that is not what I said at all. If anyone wants to work on a PR for getInitialProps support, it'd be happily merged!

[DonovanCharpin]

@isaachinman getInitialProps was supported before v8. It means it was was a choice to drop the support of this method.

Unfortunately I don’t have enough time to contribute. It still works in v7.0.1 so I’m fine with it, it’s just that I would like the new optimizations.

Thanks @slava-lu, I will check this library!

[isaachinman]

Using getInitialProps is not recommended, and I outlined the complications with supporting it. PRs welcome.

[FINDarkside]

Why is this issue closed if PRs are welcome? I see this as a quite big issue as using getServerSideProps is detrimental to performance.

[isaachinman]

@FINDarkside You've got that wrong – using getInitialProps is detrimental to perf. getServerSideProps is slightly better, and getStaticProps is best.

[isaachinman]

getInitialProps could be almost free

That is very much not the case. getInitialProps disables Automatic Static Optimization. Please read the docs.

All users are advised to use getStaticProps or getServerSideProps.

returns the exact same props for every single page

What you are describing is a problem general to NextJs, and not one that next-i18next can do anything about, until data-fetching methods are supported on _app.

[prabu-ssb]

We use runtime configuration which is available to only pages that provide getInitialProps, but is no longer received by _app.tsx via appWithTranslation.

@isaachinman is there a way we can get around this ?

[timothyhague]

We ended up migrating to: https://github.com/vinissimus/next-translate
Does everything we needed from next-i18next, and supports getInitialProps.

[prabu-ssb]

@timothyhague tried it and ran into a few problems there (aralroca/next-translate#773 (comment)), too.

We would like to continue to use next-i18next. if it is possible. But running out of alternatives ..

[isaachinman]

PRs welcome.

[prabu-ssb]

@isaachinman i would very much like to contribute, but am very pressed for time at the moment. Is v7 compatible with Next 12 ? or, is that route not possible for us, either ?

I think it was wrong to drop support for getInitialProps when it is the only way to have runtime configurations in Next.js. Agree with other comments above too.

[isaachinman]

v7 isn't actively maintained, and I'm not actually sure if you'd be able to get away with using Next 12.

To be clear, v8 was a ground-up rewrite of next-i18next, because the NextJs team decided to pull much of next-i18next's functionality which handles locales and URLs, into the framework with first class support.

next-i18next can certainly support getInitialProps again, but the work will need to be driven by the community.

Please don't bump this thread unless you are willing to lend a hand.

[Abdubek]

we are using https://nextjs.org/docs/api-reference/next.config.js/runtime-configuration and it doesn't work without getInitialProps

[prabu-ssb]

We too ended up migrating to next-translate (ref: comment by @timothyhague above). We had to write a few wrappers to ensure we did not end up with a lot of rework, though.

But if you want to stay with next-i18next, a possible workaround might be to use an api-route to expose the runtime variables. That way you do not need getInitialProps any more and can use getStaticProps for the bundles (note: this is just a "make it work" suggestion).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Cochonours]

Moved to next-translate as well. I was trying to set up i18n using this lib when I got bitten by this issue. Moving to next-translate, I ended up with less glue code.

[kolesker]

NextJS avoids support of getServerSideProps or getStaticProps if you use a Custom App.
Hence, we can't also use next-i18next anymore.

[adrai]

NextJS avoids support of getServerSideProps or getStaticProps if you use a Custom App. Hence, we can't also use next-i18next anymore.

https://locize.com/blog/next-13-app-dir-i18n/

[mattvb91]

any update on supporting this?