next-i18next: Navigating between pages with or without translations causes _app remounts
Describe the bug
When navigating from a static page that is using serverSideTranslations to a page that is not using it (or the other way around), the _app remounts. This leads to unexpected behaviour as the _app is generally used to setup context providers or run one time browser-only initializations.
Occurs in next-i18next version
Version: ^8.1.2
Steps to reproduce
- Clone https://github.com/enzoferey/next-i18n-app-unmount.
- Start the app
yarn dev. - Open the console in your browser, you will see logs on
_appmount and unmount. - Navigate from home page via the links in the page.
Expected behaviour
You will see that navigating from the home page (no serverSideTranslations usage) to the other pages (serverSideTranslations usage) the _app remounts, however when navigating between the signup and about pages (both use serverSideTranslations), the _app doesn’t remount as expected.
Screenshots

OS (please complete the following information)
- Device: MacBook Pro (13-inch, 2017, Two Thunderbolt 3 ports)
- Browser: Version 89.0.4389.90 (Official Build) (x86_64)
Notes
I’m quite sure there is something wrong around the appWithTranslation HOC. I do see that we are rendering different things based on locale existence and that could cause a whole remount, but I don’t know Nextjs i18n routing internal props well enough to hint for a solution. It might actually be an expected behaviour on your side by design of the solution, I don’t know.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 24
- Comments: 24 (9 by maintainers)
@isaachinman, this problem still happens. During page navigation, we are losing the global state via Context API.
I’m using
"next-i18next": "^10.5.0". Do we have anyone looking at this now?Created a new component:
Trans.tsx
_app.tsx
Seems to work fine
In our app all pages have translations, but even though, changing from default locale
/to same page in another locale/enwould still trigger_appremount.Update: Sorry, we just notice that without the
i18n !== null, SSR fails given a few conditions.As long as there’s no
key={locale}inWrappedComponent, _app does not remount.Fixed by #1631
Hi all, We met this issue too. We want to use next-auth and next-i18next in our nextjs project. Here is a simple example which I combined the example of next-auth and the example of next-i18next. When navigating between pages with or without translations, the session of next-auth would be undefined until you manually refresh the page. I think it’s related to the remounts of _app.
As I said, PRs welcome!
@thienna This issue is fixed in latest versions. Please let me know if you can reproduce after upgrading.
In our case our header disappears when we switch locales, until we refresh the page. We think it’s related to this bug.
@isaachinman My usage is about embedding pages from outside Next.js inside by page. As those pages will already come with i18n built-in, I want to wrap them in my Next.js applications but I don’t need any translations from
next-i18nextin them. It’s actually a common thing for businesses of a decent size that have both marketing and engineering teams working on their website. You have your marketing team working on landing pages generators, and the engineering teams integrating them and holding the infrastructure.You can certainly hack your way around requesting empty namespaces or no namespaces at all, I haven’t tried those solutions, they might work. I just think that as a user you don’t expect that the fact of not using an add-on will break Next.js architecture principles like rerendering the
_app.Thanks for pointing @skrivanos. The conditional rendering and the
localekey are definitely the two elements that can force the_appto rerender.I have patched the package on my local machine to test and removing the conditional rendering does not fix the issue. So I tried removing the
localekey. Not a winner neither. However, then I tried removing both (as thei18nexistence is tied to the_nextI18Nextexistence in the page props), and it did work as expected.I was surprised because the example repo I linked in the description does not do any locale switch at any point, so I added a few logs around to find out what’s up. It turns out that when navigating to the home page (the one that is not using
serverSideTranslations),localewill benullwhen rendered. Meanwhile when rendering the other pages, it will be set toenas expected (default locale).I tried then adding some links that would switch the locale to
deto see if after removing both this things it would still do the locale switch properly. And it does !Now, I don’t know the side effects removing these two things could have as I don’t know why there are there in the first place. From a fresh point of view, I would say that the conditional rendering can surely be removed. For the
localekey I guess it depends how theuseTranslationhook is implemented, but everything points that callers will rerender as expected when the locale changes.https://github.com/isaachinman/next-i18next/issues/1049 is kind of related indeed, but much more niche. There we are talking about fallback rendering, which is a quite small portion of the usage (static + static paths + fallback true). Here, it’s any page that doesn’t use i18n in your app.
Click to see my diff