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

DatePicker - Internationalization server client mismatch [NextJS 14.1.0 App Router] #6216

Open
thomaswanhpls opened this issue Apr 17, 2024 · 6 comments
Labels
documentation Improvements or additions to documentation enhancement New feature or request internationalization ssr

Comments

@thomaswanhpls
Copy link

thomaswanhpls commented Apr 17, 2024

Provide a general summary of the issue here

NextJS 14.1.0 using App Router
When using DatePicker as instructed in documentation server client mismatch occurs.

To mitigate a rerender on client (adapting language) for some of the components we need to provide language information on server

I've followed the steps provided here

datepicker

🤔 Expected Behavior?

The component should get correct language on SSR and not need to correct it on client.

😯 Current Behavior

The component doesn't render correct language on SSR, corrects on client resulting in a server client mismatch

💁 Possible Solution

No response

🔦 Context

No response

🖥️ Steps to Reproduce

https://stackblitz.com/edit/nextjs-arbvzx?file=components%2FDatePicker.tsx

Version

react-aria-components 1.1.1

What browsers are you seeing the problem on?

Chrome

If other, please specify.

No response

What operating system are you using?

Windows 10

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

@thomaswanhpls thomaswanhpls changed the title DatePicker - server client mismatch DatePicker - server client mismatch [NextJS 14.1.0 App Router] Apr 17, 2024
@thomaswanhpls thomaswanhpls changed the title DatePicker - server client mismatch [NextJS 14.1.0 App Router] DatePicker - Internationalization server client mismatch [NextJS 14.1.0 App Router] Apr 17, 2024
@LFDanLu
Copy link
Member

LFDanLu commented May 2, 2024

I can't seem to get your stackblitz to work, but I noticed you don't have a wrapping I18nProvider, does that help?

@thomaswanhpls
Copy link
Author

thomaswanhpls commented May 2, 2024

Thanks for taking the time @LFDanLu. Did you add routing locale? eg "en-US". I'm using /sv (swedish).
And there's a string in the datesegment component resulting in "app-index.js:35 Warning: Prop aria-valuetext did not match. Server: "Empty" Client: "Tomt""

I can't set the text manually either. That would work for me. Not sure if I would stumble into more strings that needs translation though. As for wrapping the app with I18nProvider - Since I'm using NextJS Im following the NextJS specific docs:

 // app/[lang]/layout.tsx
import {LocalizedStringProvider} from 'react-aria-components/i18n';
export default function RootLayout(
  {children, params: {lang}}:
  {children: React.ReactNode, params: {lang: string}}
) {
  return (
    <html lang={lang}>
      <body>
        <LocalizedStringProvider locale={lang} />
        {children}
      </body>
    </html>
  );
}

@LFDanLu
Copy link
Member

LFDanLu commented May 3, 2024

I might be having a brain fart, but when I open the stackblitz it just 404's after the packages are installed and next dev finishes. My understanding here is that you still need to have a wrapping i18nProvider with the locale set to whatever locale will be used on the client so that localized strings like the aria-valuetext will match between server and client. I do see what you are referring to in the docs here where it states

Render React Aria's LocalizedStringProvider component at the root of your app. This includes the strings for the user's language in the initial HTML so that the client can access them. It also passes the locale to the client, so an I18nProvider is not needed.

but looking at the code it doesn't look like LocalizedStringProvider does this in time, it sets a localeSymbol on the window which doesn't exist on the server if I'm not mistaken hence why the i18nProvider is still necessary.

@thomaswanhpls
Copy link
Author

stackblitz_demo
You need to add the locale in the url. In my case I'm adding "/sv" (swedish). NextJS router gets the params in the RootLayout and provides the locale to html tag and LocalizedStringProvider on the server.

As for wrapping the app in i18nProvider I'm not convinced it's the right approach when it comes to NextJS but I might be missing something. I've tried to apply it in the code but I can't really figure out where I would put it.

@LFDanLu
Copy link
Member

LFDanLu commented May 3, 2024

Yeah, the setup required isn't ideal here (probably a bug tbh), we'll probably want to change LocalizedStringProvider on our end to handle this for you. For now you'd have to make a client component to render the i18nProvider like so: https://stackblitz.com/edit/nextjs-tep8sy?file=app%2F[lang]%2Flayout.tsx,app%2F[lang]%2FLocaleProvider.tsx,app%2F[lang]%2Fpage.tsx

some docs in NextJS about this: https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns#using-context-providers

@thomaswanhpls
Copy link
Author

thomaswanhpls commented May 6, 2024

Thank you for sharing your thoughts about this! 🙌 @LFDanLu

@LFDanLu LFDanLu added documentation Improvements or additions to documentation enhancement New feature or request labels May 7, 2024
@github-project-automation github-project-automation bot moved this to ✏️ To Groom in RSP Component Milestones May 7, 2024
@LFDanLu LFDanLu moved this from ✏️ To Groom to 📋 Waiting for Sprint in RSP Component Milestones Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request internationalization ssr
Projects
Status: 📋 Waiting for Sprint
Development

No branches or pull requests

2 participants