Browser bundle includes namespaces that are unrelated to a given page

Not sure if it’s an upstream bug or not, but I’ve noticed that the size of initialI18nStore grows as the website is warming up. Opening any page for the first time adds dependent namespaces to the source of all other pages viewed later. If a website consists of quite a few pages, the overall size of initialI18nStore can grow rather big and thus diminish the benefits of splitting translations into files. I’m quite sure that my projects did not suffer from this problem before I tried next-i18next, but switching to it also meant for me the upgrading of i18next.

Steps to reproduce

Worked both for 0.8.0 and the latest master)

1. cd example; yarn; yarn dev;
2. Open http://localhost:3000/
3. View page source, observe that initialI18nStore includes
   {"en": {"common": ..., "footer": ...}}
4. Go to http://localhost:3000/second-page and refresh the page (so that it got server-rendered)
5. Return to http://localhost:3000/, refresh the page again
6. View page source, observe that initialI18nStore includes
   {"en": {"common": ..., "footer": ..., "second-page": ...}}
   Expected content:
   {"en": {"common": ..., "footer": ...}}

[isaachinman]

Let’s continue discussion in #54.

[isaachinman]

Happy to report that I think I’ve found a much more sane, workable solution.

Fix comes with 2386bf2.

I finally stumbled across react-tree-walker, which seems to be well-written, well-maintained, and an absolute godsend for our use case here.

Instead of creating a modified withNamespaces HOC and trying to keep track of a component tree’s namespace deps there (which is an inherently fraught idea), we will walk the component tree inside getInitialProps, as this will be request-specific, and we’re provided with the page-level Component inside the first argument object, thanks to NextJs.

Now that we have the initialLanguage and can walk a component tree based on a specific request, we can reliably produce exactly the initialI18nStore required to render that specific request - nothing more and nothing less.

Performance is obviously the biggest concern here. During prod SSR of the example, I’m seeing walk times of 3ms, which isn’t great considering how simple a tree it is.

Hopefully in the future, a method will solving this problem will come to my attention that completely avoids the issue of re-walking/re-rendering the tree. Until now, I am quite happy with this solution.

Another added benefit is that we no longer need to maintain a custom withNamespaces HOC, and can simply re-export directly from react-i18next.