Skip to content
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

PoC: Translations for Next.js fallback pages #594

Open
wants to merge 1 commit into
base: canary
Choose a base branch
from

Conversation

berndartmueller
Copy link
Contributor

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

default

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

fallback-translations

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
Copy link
Contributor Author

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

@aralroca aralroca closed this May 21, 2021
@aralroca aralroca deleted the branch aralroca:canary May 21, 2021 09:34
@berndartmueller
Copy link
Contributor Author

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

@aralroca
Copy link
Owner

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

@aralroca aralroca reopened this May 22, 2021
@aralroca aralroca deleted the branch aralroca:canary November 7, 2021 15:07
@aralroca aralroca closed this Nov 7, 2021
@berndartmueller
Copy link
Contributor Author

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

@aralroca aralroca reopened this Nov 7, 2021
@aralroca
Copy link
Owner

aralroca commented Nov 7, 2021

@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. 👏

Copy link
Owner

@aralroca aralroca left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

blocking


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>
    </>
  )
}

fallbacktrue


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!!!

@aralroca aralroca deleted the branch aralroca:canary February 14, 2022 15:31
@aralroca aralroca closed this Feb 14, 2022
@aralroca aralroca reopened this Feb 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants