Next.js 12.3.0 AppProps generic breaks appWithTranslation type

[matchatype]

Next.js 12.3.0 #38867 introduces the use of a generic for AppProps type, that is incompatible with appWithTranslation type.

To Reproduce

The following example causes a TypeScript error (TS2345):Argument of type '({ Component, pageProps }: AppProps<{ session: Session;}>) => JSX.Element' is not assignable to parameter of type 'ComponentType<AppProps>'.

const App = ({Component, pageProps}: AppProps<{session: Session}>) => (
  <SessionProvider session={pageProps.session}>
    <ThemeProvider>
      <Component {...pageProps} />
    </ThemeProvider>
  </SessionProvider>
)

export default appWithTranslation(App)

[adrai]

Would you like to send a Pull Request to address this?

[gazs]

@adrai @matchatype I've opened a PR that apparently addresses the issue: https://github.com/i18next/next-i18next/pull/1948

[adrai]

@adrai @matchatype I've opened a PR that apparently addresses the issue: #1948

@matchatype let me know if this works for you, then we'll merge that PR and release a new version

[matchatype]

@gazs I don't think you want to do that. What you want is extend SSRConfig to allow whatever the pageProps are and include _nextI18Next as well.

[gazs]

extend SSRConfig to allow whatever the pageProps are and include _nextI18Next as well.

pageProps is {} and extending it is essentially what the existing code does as far as I understand. however it fails because the Validator type expects a {} -- unsure where that comes from so far

[Zerebokep]

Stumbled about the same problem using react-query with appWithTranslation. react-query requires a dehydratedState field in pageProps, extending pageProps causes the error described.

[renadr]

I have the same issue here. Is there a way to solve this problem locally?

[matchatype]

I'm sorry, I don't time to help right now, but I guess you can trick TS with the following:

export default appWithTranslation<never>(App)

[ebrahimhassan121]

you can use this till they fix this bug export default appWithTranslation(MyApp) as FC

[aziaziazi]

you can use this till they fix this bug export default appWithTranslation(MyApp) as FC

Thanks Ebrahim, worked for me with a little tweak: export default appWithTranslation(MyApp as FC)

[wjpg]

Is declaring a PageProps type which extends SSRConfig not an appropriate solution?

type PageProps = SSRConfig & Record<string, any>
<AppProps<PageProps>>

[oddsund]

@gazs I don't think you want to do that. What you want is extend SSRConfig to allow whatever the pageProps are and include _nextI18Next as well.

As I see it, the PR is actually correct. _nextI18Next is nullable, as it may or may not be provided in each page, depending on if the page calls serverSideTranslations. Looking at the code for appWithTranslation, _nextI18Next is even checked for null/undefined. Also, I would say that _nextI18Next is an internal library type which the consumer shouldn't need to care about when calling appWithTranslation.

So #1948 would fix this. It can even include some cleanup in the function, as there are a few redundant if-checks.

Ref the "extending with what pageProps are" solution; is it even possible in Typescript as of today? Wouldn't that be a higher kind type, which isn't implemented? Ref https://github.com/microsoft/TypeScript/issues/1213

Also, extending the type would still require the caller to send in the SSRConfig, which is not expected.

Another workaround:

const MyApp = ({Component, pageProps}: AppProps<YourType & SSRConfig>) => (

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Zerebokep]

stale bump

[adrai]

a new major version will be published as soon as -> #1966

[emrysal]

@adrai the work done (amazing work by the way, just read up on all the activity over the last month on this project) concluded 9 days ago - is the v13.0.0 tag imminent?

[adrai]

@adrai the work done (amazing work by the way, just read up on all the activity over the last month on this project) concluded 9 days ago - is the v13.0.0 tag imminent?

Just a TypeScript topic needs to be done and maybe another package optimization... then v13 will be released.