-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Confusion with nextjs example #397
Comments
The problem i see is: // commonjs (dist/commonjs)
const i18n = require('i18next'); // -> you get the i18next instance
// webpack (dist/es)
import i18n from 'i18next'; // -> you get the i18next instance
// typescript
import i18n from 'i18next'; // -> you get an object { default: i18nextInstance, ... } Honestly if i would restart i would start using only named exports (just remove that default export as it is used non-consistent). module.exports = {
i18nInstance, // result of require('i18next') + manipulations like .use(XHR)
I18n: i18n.default, // Class to be used in translate hocs later
getInitialProps, // function, detached from i18n
} I'm not sure if that solves it...i18nInstance is the correct thing to use in webpack, i18n.default will be undefined. For typescript you now can use the named export I18n... ?!? |
I my i18n.ts I use
That's right, but that gets solved by This makes it easier to track what depends on what and also removes a combination I got trapped by: https://github.com/zeit/next.js/blob/dbb1b732a06e92f8730d26fa01dac4d53c744732/examples/with-react-i18next/i18n.js#L59 We are exporting My point is that if we change what's being exported in the example's I'm happy to submit a PR to next.js to better describe what I mean. |
agree...i would say change that export...as it does not break - it does not hurt ;) |
I've got one more little question left 😄 What's the best way to toggle It'd be great if the example had |
@kachkaev not so deep into next.js...from guessing i would think process.env.NODE_ENV exists on client too (like in create-react-app) but chance is my guessing is wrong ;) |
You're right, |
I was playing with next.js + react-i18next + typescript this weekend and fell into a pretty unfortunate trap, which took a while to investigate. It is to do with the interface of i18n.js file.
Because
i18n.js
usesrequire
&module.exports
and then pages go forimport i18n from '../i18n';
, it's easy to get lost in what's being passed around. Because of this I ended up providingtranslate()
hoc with a wrongi18n
(i.e., a module object, not a class) here:react-i18next/example/nextjs/pages/index.js
Line 21 in bf65822
This happened to me partially because I was using
import
/export
everywhere inside my TypeScript project and so quite a lot of time was lost 😅I'm wondering if
module.exports
could be made more explicit ini18n.js
to help others avoid the same confusion. I'd export three non-default things rather than justi18n
(which as I turned out has got.default
property, equal toI18n
class 😮 ). These exports would be:Here is how a modified version of
i18n.js
looks in my TypeScript project: https://github.com/callthemonline/client-nextjs/blob/63d5d15cadd1879fd62e20d045f5c12a35d6406e/server/i18n.tsWDYT of changing module exports @jamuhl? I'll be happy to submit a PR to the next js repo (because the example is a couple of commits ahead) and we'll then sync this repo's example too.
The text was updated successfully, but these errors were encountered: