Next-i18next: SSR unfriendly approach demonstrated in example

Created on 15 Feb 2021  路  2Comments  路  Source: isaachinman/next-i18next

Describe the bug

In example app i18next instance imported
https://github.com/isaachinman/next-i18next/blob/8b6d63740c4acac8f6707cec0c8a74d59fca7ae7/examples/simple/pages/index.js#L2
This way i18n.language works on client side only, but has undefined value on server side.
So if you for example want to render current language in SSR page - there will be an error because of client/server value inconsistency.

Occurs in next-i18next version

v7.0.1

Steps to reproduce

In this line:
https://github.com/isaachinman/next-i18next/blob/8b6d63740c4acac8f6707cec0c8a74d59fca7ae7/examples/simple/pages/index.js#L15
try to render {i18n.language} and check logs for error

How to fix

To make it work as expected we should not import i18next but take it from component props as suggested here:
https://react.i18next.com/latest/withtranslation-hoc

import React from 'react';
import { withTranslation } from 'react-i18next';

function MyComponent({ t, i18n }) {
  return <p>{t('my translated text')}</p>
}

export default withTranslation()(MyComponent);

Most helpful comment

Sure, makes sense. Feel free to open a PR with these changes.

All 2 comments

Sure, makes sense. Feel free to open a PR with these changes.

Hi there, I have just released [email protected], which uses the internationalised routing built into NextJs v10+. This new version of next-i18next is quite different, thus making this PR no longer relevant. Thanks!

Was this page helpful?
0 / 5 - 0 ratings