{"action":"created","issue":{"url":"https://api.github.com/repos/zeit/next.js/issues/4532","repository_url":"https://api.github.com/repos/zeit/next.js","labels_url":"https://api.github.com/repos/zeit/next.js/issues/4532/labels{/name}","comments_url":"https://api.github.com/repos/zeit/next.js/issues/4532/comments","events_url":"https://api.github.com/repos/zeit/next.js/issues/4532/events","html_url":"https://github.com/zeit/next.js/issues/4532","id":328874116,"node_id":"MDU6SXNzdWUzMjg4NzQxMTY=","number":4532,"title":"Logic of with-react-i18next is incompatible with _app.js","user":{"login":"kachkaev","id":608862,"node_id":"MDQ6VXNlcjYwODg2Mg==","avatar_url":"https://avatars3.githubusercontent.com/u/608862?v=4","gravatar_id":"","url":"https://api.github.com/users/kachkaev","html_url":"https://github.com/kachkaev","followers_url":"https://api.github.com/users/kachkaev/followers","following_url":"https://api.github.com/users/kachkaev/following{/other_user}","gists_url":"https://api.github.com/users/kachkaev/gists{/gist_id}","starred_url":"https://api.github.com/users/kachkaev/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kachkaev/subscriptions","organizations_url":"https://api.github.com/users/kachkaev/orgs","repos_url":"https://api.github.com/users/kachkaev/repos","events_url":"https://api.github.com/users/kachkaev/events{/privacy}","received_events_url":"https://api.github.com/users/kachkaev/received_events","type":"User","site_admin":false},"labels":[{"id":475935585,"node_id":"MDU6TGFiZWw0NzU5MzU1ODU=","url":"https://api.github.com/repos/zeit/next.js/labels/good%20first%20issue","name":"good first issue","color":"1BDF7E","default":true},{"id":455907198,"node_id":"MDU6TGFiZWw0NTU5MDcxOTg=","url":"https://api.github.com/repos/zeit/next.js/labels/help%20wanted","name":"help wanted","color":"128A0C","default":true}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2018-06-03T23:57:42Z","updated_at":"2018-06-05T22:22:41Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"# Examples bug report / feature request\r\n\r\n## Example name\r\n\r\n* [with-react-i18next](https://github.com/zeit/next.js/tree/canary/examples/with-react-i18next)\r\n* [with-i18next](https://github.com/zeit/next.js/tree/canary/examples/with-i18next) (possibly)\r\n\r\n## Describe the bug  / feature request\r\n\r\nLooks like [`with18next()` HOC](https://github.com/zeit/next.js/blob/canary/examples/with-react-i18next/lib/withI18next.js) in `with-react-i18next` example is incompatible with `_app.js` (added in Next v6). Although wrapping each page into the HOC is still possible, this approach has at least these two drawbacks:\r\n\r\n* The layout defined in `_app.js` cannot be translated since the components end up _above_ `with18next(['ns'])(PageComponent)`.\r\n* Going between pages flushes the DOM tree since `with18next()` creates separate wrapper components on each page (I may be not 100% here).\r\n \r\nThe `with-apollo` example [has been updated recently](https://github.com/zeit/next.js/pull/4420) and ApolloProvider is now a part of `_app.js`, which is pretty neat. It'd be great if `with-react-i18next` could undergo a similar transformation. I've just tried to propose this change myself, but am giving up after over three hours 😅 \r\n\r\nThere's one caveat that should be taken into account when implementing the new logic: a collection of namespaces used by a page needs to be passed into `_app.js`. I suggest that these namespaces can be either sourced from `getInitialProps()`:\r\n\r\n```jsx\r\nexport default class MyPage extends Component {\r\n  static getInitialProps() {\r\n    return { i18nextNamespaces: ['ns1', 'ns2'] };\r\n  }\r\n  render() {\r\n    return <div>{this.props.t('hello')}</div>;\r\n  }\r\n}\r\n```\r\n\r\nAlternatively, `i18nextNamespaces` can be defined in a static property to avoid implementing `getInitialProps()` in the simplest cases: \r\n\r\n```jsx\r\nexport default class MyPage extends Component {\r\n  static public i18nextNamespaces = ['ns1', 'ns2'];\r\n  render() {\r\n    return <div>{this.props.t('hello')}</div>;\r\n  }\r\n}\r\n```\r\n\r\n```jsx\r\nconst MyPage = ({t}) => <div>{t('hello')}</div>;\r\nMyPage.i18nextNamespaces = ['ns1', 'ns2'];\r\nexport default MyPage;\r\n```\r\n\r\nIdeally, these namespaces should be detected automatically depending on which ones are used down the tree (`translate(['ns1'])(Component1)`, `translate(['ns2', 'ns3'])(Component2)`). This magic behaviour would be similar to what Apollo does with executing all queries in the tree on the server and building client-side cache based on that. However, I'm not sure how easy it would be to implement this trick in `react-i18next`.\r\n\r\n## System information\r\n - Version of Next.js: 6.0.3\r\n\r\ncc @jamuhl"},"comment":{"url":"https://api.github.com/repos/zeit/next.js/issues/comments/394879502","html_url":"https://github.com/zeit/next.js/issues/4532#issuecomment-394879502","issue_url":"https://api.github.com/repos/zeit/next.js/issues/4532","id":394879502,"node_id":"MDEyOklzc3VlQ29tbWVudDM5NDg3OTUwMg==","user":{"login":"kachkaev","id":608862,"node_id":"MDQ6VXNlcjYwODg2Mg==","avatar_url":"https://avatars3.githubusercontent.com/u/608862?v=4","gravatar_id":"","url":"https://api.github.com/users/kachkaev","html_url":"https://github.com/kachkaev","followers_url":"https://api.github.com/users/kachkaev/followers","following_url":"https://api.github.com/users/kachkaev/following{/other_user}","gists_url":"https://api.github.com/users/kachkaev/gists{/gist_id}","starred_url":"https://api.github.com/users/kachkaev/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kachkaev/subscriptions","organizations_url":"https://api.github.com/users/kachkaev/orgs","repos_url":"https://api.github.com/users/kachkaev/repos","events_url":"https://api.github.com/users/kachkaev/events{/privacy}","received_events_url":"https://api.github.com/users/kachkaev/received_events","type":"User","site_admin":false},"created_at":"2018-06-05T22:22:41Z","updated_at":"2018-06-05T22:22:41Z","author_association":"CONTRIBUTOR","body":"@jamuhl It’d be great if you could have a look at just using i18next in _app.js. If that works, I can nest Apollo into your wrapper and that will be it! In fact, Apollo does need to be inside i18n context, because things like GraphQL endpoint or query params can depend on the current language."}}
{"actor":{"display_login":"kachkaev"}}