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

Properly support custom pages/_app components with Server Components #30996

Closed
devknoll opened this issue Nov 4, 2021 · 1 comment · Fixed by #33149
Closed

Properly support custom pages/_app components with Server Components #30996

devknoll opened this issue Nov 4, 2021 · 1 comment · Fixed by #33149
Assignees

Comments

@devknoll
Copy link
Contributor

devknoll commented Nov 4, 2021

Initially, you might assume that pages/_app will just become pages/_app.client when used with Server Components. However, this actually doesn't make sense: pages/_app is meant to be common to every page on the client and server. If it were a Client Component, this would no longer be the case.

Instead, pages/_app should become a Server Component: pages/_app.server. Rather than requiring that every page is wrapped on the client, this becomes an optional step that an app may do explicitly:

import MyRoot from '../components/my-root.client'

// pages/_app.server
export default function App({ children }) {
  return <MyRoot>{children}</MyRoot>
}

Note that the Server Component pages/_app.server no longer receives Component and pageProps as props, because the entire tree (for full page loads) is provided by the Server Component endpoint.

This addresses a long standing issue where navigating between pages would cause common shell components to be unmounted and remounted because of the intermediate page Component. With Server Components, React can properly reconcile the new page and old page, and retain state on mounted components when possible (provided other reconciliation criteria aren't violated, e.g. keys).

@kodiakhq kodiakhq bot closed this as completed in #33149 Jan 14, 2022
kodiakhq bot pushed a commit that referenced this issue Jan 14, 2022
## Feature

Resolves #30996

- [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
@balazsorban44
Copy link
Member

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

@vercel vercel locked as resolved and limited conversation to collaborators Feb 14, 2022
natew pushed a commit to natew/next.js that referenced this issue Feb 16, 2022
## Feature

Resolves vercel#30996

- [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
nevilm-lt pushed a commit to nevilm-lt/next.js that referenced this issue Apr 22, 2022
## Feature

Resolves vercel#30996

- [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants