PoC: Translations for Next.js fallback pages

[berndartmueller]

Fixes #575

See https://nextjs.org/docs/basic-features/data-fetching#fallback-pages

Page props on Next.js fallback pages are empty ({}). Therefore translations are also missing.

My idea to circumvent this is providing a new HOC withFallbackTranslation() to wrap any Next.js page which should have fallback translations. This HOC adds a static function __PAGE_NEXT_NAMESPACES to the component. This function is called within the appWithI18n component.

As fallback pages do not provide any way to use async operations, I had to add a way to load translations sync. That's why I also added a new config property loadLocaleFromSync.

To demonstrate that it works, I added a new route to examples/complext demo -> http://localhost:3000/more-examples/fallback/example-not-exists

Here are two Gifs to better show the effect:

Default behaviour for translations on fallback pages.

Notice the flicker while it defaults to the translation key.

Route: http://localhost:3000/more-examples/dynamicroute/example11?another=another+param

Fallback pages wrapped with HOC withFallbackTranslation

No flicker at all. The translations are loaded from the beginning on.

Route: http://localhost:3000/more-examples/fallback/example-not-exists?another=another+param

This PR should be seen as a proof of concept. There are certainly a few things that can and should be refactored/improved.

I'm looking forward to your feedback.

[berndartmueller]

Did anyone of the maintainers already checkout this PR? I would be very interested in your feedback :)

[berndartmueller]

@aralroca Was there any particular reason why you closed this PR?

[aralroca]

@berndartmueller Sorry, I accidentally deleted the canary branch in the last release and the PR was closed automatically. I reopen it

[berndartmueller]

@aralroca Is there any interest in this PR/Feature?

[aralroca]

@berndartmueller Sorry, I removed the canary branch when I made the release by accident and the PRs that were open have been closed. I am committed to review the PR during this week. Sorry for the delay. And thank you very much for the contribution. 👏

[aralroca]

It's good to solve the problem, thanks for the contribution @berndartmueller! 😊 And sorry for the delay in reviewing it 🙏

I think the ideal would be that this was transparent without growing the library in code and without more work for users. I still don't know if it's feasible, but I'll tell you about something I found. Exploring the problem a little, I found two ways to deactivate the flick:

---

Using SSR

I see that changing fallback: true, for fallback: 'blocking' the translations work correctly without any flick.

It seems that the difference (if I am not mistaken) is that the fallback page is loaded in SSR (fallback: 'blocking') instead of CSR (fallback: true). This fixes the flick when loading translations.

---

Using CSR

If you want to avoid SSR, with fallback: true you can still avoid the flick with the isFallback.

export default function DynamicRoute({ title = '' }) {
-  const { query } = useRouter()
+  const { query, isFallback } = useRouter()
  const { t, lang } = useTranslation()

+  if(isFallback) return null

  return (
    <>
      <h1>{title}</h1>
      <h2>{t`more-examples:dynamic-route`}</h2>
      <h3>
        {query.slug} - {lang}
      </h3>
      <Link href="/">
        <a>{t`more-examples:go-to-home`}</a>
      </Link>
    </>
  )
}

---

This is not to say that your PR is not valid. But from my lack of knowledge, I would like to understand when it is useful to use the flick (translated) rather than avoiding the flick. Thanks!!!