i18next & common questions

[7iomka]

Hello! Thank you very much for your work!
It is possible to continue usage of i18next but without locize vendor?
Advise steps for implementation please!

PS: I tried using next-i18next but their configuration uses getInitialProps in _app and this disables static optimization. The developers themselves refuse to change anything in this direction.

Then I found your repository and studied the approaches you proposed!
Thanks for any help and awesome ideas in context of problem solving with latest next.js!

[Vadorequest]

Hello @7iomka :)

Yes, it's totally possible to do without Locize, even though no official preset was released without Locize built-in so far. (I'll do that someday, but want to polish current SSG support work in progress before)

Also, I invite you to check the current PR regarding SSG support:
#42

This branch provides full SSG support using the latest Next.js version.
I advise you start from it, and remove locize.

To remove locize, the easiest approach would be to override the following:

• next-right-now/src/utils/nextjs/SSG.ts

  Line 43 in d120423

  const i18nTranslations: I18nextResources = await fetchTranslations(lang); // Pre-fetches translations from Locize API

  Currently loads translations from Locize API, instead you should load your i18next translation your own way (filesystem?)

• next-right-now/src/components/appBootstrap/MultiversalAppBootstrap.tsx

  Line 60 in d120423

  const i18nextInstance: i18n = i18nextLocize(lang, i18nTranslations); // Apply i18next configuration with Locize backend

  takes i18nTranslations (currently fetched from Locize API) and init the i18next with it, there is nothing to change here, it's just for clarity :)

• next-right-now/src/utils/i18n/i18nextLocize.ts

  Line 371 in a7307e0

  map(plugins, (plugin) => i18nInstance.use(plugin));

  Remove all Locize plugins (line 342 and below)

I believe those small manipulations should be enough to get rid of Locize, using the filesystem may be the easiest way. Note that you need to respect the i18next spec regarding data format though.

Here is an example of i18nTranslations:

{
  "en": {
    "common": {
      "examples": {
        "i18n": {
          "dynamicPluralTranslation": "We found {{count}} solution for you.",
          "dynamicPluralTranslation_plural": "We found {{count}} solutions for you.",
          "dynamicTranslation": "Dynamic content: <1>{{uuid}}</1>",
          "pluralTranslation": "Translation with pluralisation",
          "pluralTranslation_plural": "Translation with pluralisations",
          "simpleTranslation": "Simple translation"
        }
      },
      "footer": {
        "terms": {
          "link": "Terms",
          "text": "All rights reserved"
        }
      },
      "nav": {
        "adminSite": {
          "link": "Admin site"
        },
        "examplesPage": {
          "link": "Examples"
        },
        "githubDocPage": {
          "link": "Documentation"
        },
        "githubPage": {
          "link": "Source code"
        },
        "indexPage": {
          "link": "Home"
        },
        "productsPage": {
          "link": "Products"
        },
        "termsPage": {
          "link": "Terms"
        }
      }
    }
  }
}

[Vadorequest]

@jajourda FYI this could be useful to you too :)

[7iomka]

@Vadorequest Thanks you very much! I will check proposed steps a little later.
I'm worked with my own branch, because I don’t need much of what your branch offers (analytics, logging, multiple utils)
But in order to borrow your approaches to reorganizing code in _app, I now need to study a lot of your code, leaving only what I need. Ultimately, when this routine work is over, I hope that I get a working code :)
Next.js did a great job of separating rendering options, but with regard to the implementation of user code that users had previously initialized in _app via getInitialProps, it is unclear how to "quickly" abandon this.

Hopefully in the future next will make it possible to determine the type of page rendering in _app.
And I like your suggestions on this:

Spoiler

{ mode: 'SSG', origin: 'server', servedBy: 'server' } - Page served dynamically (getStaticProps, server build, when working locally)
{ mode: 'SSG', origin: 'server', servedBy: 'browser' } - Page served dynamically (getStaticProps, client re-render, when working locally)
{ mode: 'SSG', origin: 'browser', servedBy: 'browser'} - Page served statically (getStaticProps, static bundle, client-side)
{ mode: 'SSR', origin: 'server', servedBy: 'server'} - Page served dynamically (getInitialProps, server initial render)
{ mode: 'SSR', origin: 'browser', servedBy: 'browser'} - Page served dynamically (getInitialProps, client re-render/render (CSR))
{ mode: 'SSR' (SSP ?), origin: 'server', servedBy: 'server'} - Page served dynamically (getServerSideProps, called from server directly (e.g: page refresh)
{ mode: 'SSR' (SSP ?), origin: 'browser', servedBy: 'server'} - Page served dynamically (getServerSideProps, called from browser and proxied through API (e.g: client-side navigation to a page using getServerSideProps)

[Vadorequest]

Yes, it does come with a lot of built-in stuff, at some point I may release lighter presets. Current preset is actually based on our own internal requirements, hence the complexity.

I should make a RFC about this suggestion actually... Timer (from Next.js core team) asked me ahah

[7iomka]

Yes, it does come with a lot of built-in stuff, at some point I may release lighter presets. Current preset is actually based on our own internal requirements, hence the complexity.

I should make a RFC about this suggestion actually... Timer (from Next.js core team) asked me ahah

Yes, you did a lot of work to create such an assembly with such a set of different tools for different tasks. For newcomers (such as me) it is very difficult to tear out some functional isolated. For example, I am not familiar with architecture of now deployment, and I'm a little confused about how I define this env variable for various node_env (I have this question because I see you use multiple checking rules like if (process.env.APP_STAGE === 'development').
I started reading the documentation for next.js
https://nextjs.org/docs/basic-features/environment-variables#exposing-environment-variables
Do I understand correctly what I need to create (?)

1. .env.development
   with
   APP_STAGE=development

2. .env.production
   with
   APP_STAGE=production

3. .env
   with my common needed and non-sensitive env variables

4. .env.local / .env.development.local / .env.production.local (git ignored)
   with sensitive env variables (like api keys, etc.)

5. in next.config.js in env field
   only env variables computed by other env variables or calculated by other source of data

Like this

// Non duplicated environment variables (automatically resolved, must not be specified in the .env.build file)
  BUILD_TIME: date.toString(),
  BUILD_TIMESTAMP: +date,
  APP_NAME: packageJson.name,
  APP_VERSION: packageJson.version,
  UNLY_SIMPLE_LOGGER_ENV: process.env.APP_STAGE, // Used by @unly/utils-simple-logger - Fix missing staging logs because it believes we're in production

And after this next.js will handle and will use needed env variables for each stage (development or production). One different with your configs is that with this approach we won't have staging stage.

[Vadorequest]

Actually, you only need to create what's recommended in https://unlyed.github.io/next-right-now/getting-started/quick-start, which is .env.build.

If you deploy on Vercel, only the now.*.json files are used in staging/production. The .env.build file is only used locally.

Reading https://unlyed.github.io/next-right-now/concepts/env-and-stages should help, too.

[7iomka]

Actually, you only need to create what's recommended in https://unlyed.github.io/next-right-now/getting-started/quick-start, which is .env.build.

If you deploy on Vercel, only the now.*.json files are used in staging/production. The .env.build file is only used locally.

Reading https://unlyed.github.io/next-right-now/concepts/env-and-stages should help, too.

Ok! Thanks.
One last question (may be need to create another issue with questions like this).

it's possible to rewrite _app as functional component (currently you use class component)?
I try this

const MultiversalPageEntryPoint = ({ Component, pageProps }: MultiversalAppBootstrapProps) => {
   return <MultiversalAppBootstrap {...**WHAT PROPS to pass there???**} />
}

[Vadorequest]

No, it's not possible to use a class component (AFAIK), because it has to extends the native import NextApp from 'next/app';, and relies on it for error handling and more.

[7iomka]

No, it's not possible to use a class component (AFAIK), because it has to extends the native import NextApp from 'next/app';, and relies on it for error handling and more.

My question is not closely related to your assembly.
I want to implement my _app as a functional component (in accordance with the recommended use case in the documentation).
In my assembly I don't use error handling and I don't need componentDidCatch
So I don't know what type of props I need to pass to MultiversalAppBootstrap component

[Vadorequest]

I suggest you ask on the Next.js community for this, but my recommendation is to keep it as it. You should look at what import NextApp from 'next/app'; does underneath, I'm fairly sure Next.js app can't work without out it. It's necessary, IMHO.

[7iomka]

@Vadorequest , Official docs example https://nextjs.org/docs/basic-features/typescript#custom-app - this is functional component and with this all works fine
My question is how to integrate your component MultiversalAppBootstrap in _app if it is a functional component?

[Vadorequest]

Oh, interesting, they've changed that. Thanks, I'll use a functional component too then :)

Based on their examples:

function MyApp(props: AppProps) {
  return <MultiversalAppBootstrap {...props} />
}

This should do it.

[7iomka]

Oh, interesting, they've changed that. Thanks, I'll use a functional component too then :)

Based on their examples:

function MyApp(props: AppProps) {
  return <MultiversalAppBootstrap {...props} />
}

This should do it.

There is still work to be done on indicating the correct type, because now it shows an error in my assembly.
Perhaps these are some of my improvements. Do you have any errors with this use?
My current workaround is return <MultiversalAppBootstrap {...(props as any)} />;

[7iomka]

Oh
I found workaround: just import Props type from MultiversalAppBootstrap component
and pass it to MyApp(props: Props) - it fixes error with typing but I don't know if this is correct way)