Jul 03, 2023
Colin Sidoti
Already know the /pages directory? Here's a simple way to migrate to the /app directory in Next.js 13.
The Next.js App Router
The App Router already has a migration guide
We want to demonstrate a 1-to-1 mapping of Pages Router to App Router, but this is not a complete migration. In the snippets below you will see obvious potential refactors, and that is on purpose.
As an example, one App Router snippet below still has function called getServerSideProps
. It doesn't make sense to keep that name, but we want to demonstrate how getServerSideProps
can be expressed in the context of the App Router.
One more disclaimer: this will not explain how to migrate everything. We focused on the best practices for the Pages Router in Next.js 12.3, but left out older APIs like getInitialProps
.
You probably know that the App Router supports both Client Components and the newly introduced Server Components.
Before the App Router, Client Components were just called Components. We want to clarify that after the App Router, absolutely nothing has changed about them.
Most importantly, within the App Router, Client Components are still rendered on the server, then hydrated on client. Search engine crawlers can still index their HTML.
Within this guide, the React code from your Pages Router will be copied to new files and labeled with "use client"
at the top. This is expected, since we're doing a 1-to-1 mapping.
Before you can get started with the App Router, you will first need to create a /app directory as a sibling to your /pages directory.
If you have a Custom Document
/pages/_document.tsx1import { Html, Head, Main, NextScript } from 'next/document'23export default function Document() {4return (5<Html>6<Head />7<body>8<Main />9<NextScript />10</body>11</Html>12)13}
We need to convert this into a Root Layout
<Html>
and </Html>
with the lowercase, HTML equivalent <html>
and </html>
. For accessibility, it's best to add a language to your opening tag, like <html lang="en">
<Head>
and </Head>
with the lowercase, HTML equivalent <head>
and </head>
. If you only have a self-closing <Head />
, you can remove it entirely<Main />
with {children}
, and update the default function export to accept a {children}
argument. For Typescript users, children
is of type React.ReactNode
<NextScript />
entirelyWhen complete, /app/layout.tsx should look more like this, plus your customizations:
/app/layout.tsx1export default function RootLayout({2children,3}: {4children: React.ReactNode5}) {6return (7<html lang="en">8<body>{children}</body>9</html>10)11}
Important: /app/layout.tsx is required in the /app directory. If you do not have a Custom Document, you can copy-paste the above sample directly into /app/layout.tsx.
Note: If you do not have a file at /pages/_app.tsx you can skip to Step 3.
If you have a Custom App
/pages/_app.tsx1import type { AppProps } from 'next/app'23export default function MyApp({ Component, pageProps }: AppProps) {4return <Component {...pageProps} />5}
The /app directory does not have a 1-to-1 corollary for a Custom App, but it can easily be expressed in the new structure:
"use client"
(with the quotes)Component
and pageProps
arguments, it should only take a children
argument. For Typescript users, children
is of type React.ReactNode
.<Component {...pageProps} />
with <>{children}</>
, or just {children}
if you have another wrapping elementpageProps
, please comment them out for now, and revisit them on a page-by-page basis. Next.js has added a new metadata APIpageProps
hereMyApp
to ClientLayout
. It is not strictly necessary, but it is more conventionalWhen complete, /app/ClientLayout.tsx should look more like this, plus your customizations:
/app/ClientLayout.tsx1"use client"23export default function ClientLayout({4children,5}: {6children: React.ReactNode7}) {8return <>{children}</>9}
Now, this is where things get a little different:
ClientLayout
inside /app/layout.tsxOpen /app/layout.tsx, import ClientLayout, and use it to wrap {children}. When complete, your Root Layout should look like this, plus any customizations from Step 1:
/app/layout.tsx1import ClientLayout from "./ClientLayout"23export default function RootLayout({4children,5}: {6children: React.ReactNode7}) {8return (9<html lang="en">10<body>11<ClientLayout>12{children}13</ClientLayout>14</body>15</html>16)17}
Now that your layout has been copied into the App Router, it's time to start migrating your pages one-by-one. There will be a few steps for each page:
For the avoidance of doubt: yes, we will be splitting your Pages Router page into two files: one for data fetching and one for rendering.
Both the Pages Router and the App Router are "filesystem routers," but they are organized slightly differently. In the App Router, each page gets its own directory. Here is how to determine the directory name:
Inside your page directory, create a file called page.tsx to handle data fetching. Copy-paste the following snippet as the foundation of this file (Note: we will create ClientPage.tsx in 3.3.):
page.tsx1import ClientPage from "./ClientPage"23export default async function Page() {4return <ClientPage />5}
If your Pages Router file does not have any data fetching, you can continue on to the next step. Otherwise, find your data fetcher below to learn how it can be migrated:
Migrating getStaticProps to the App Router
Consider the following is your implementation of getStaticProps
:
1export const getStaticProps: GetStaticProps<PageProps> = async () => {2const res = await fetch('https://api.github.com/repos/vercel/next.js')3const repo = await res.json()4return { props: { repo } }5}
To migrate this with as little modification as possible, we will:
getStaticProps
into page.tsxgetStaticProps
from within our Page
componentexport const dynamic = "force-static"
so the page data is fetched once and cached, not refetched on every loadClientPage
componentHere is the end result:
page.tsx1import ClientPage from "./ClientPage"23export const getStaticProps: GetStaticProps<PageProps> = async () => {4const res = await fetch('https://api.github.com/repos/vercel/next.js')5const repo = await res.json()6return { props: { repo } }7}89export const dynamic = "force-static"1011export default async function Page() {12const { props } = await getStaticProps();13return <ClientPage {...props} />14}
Migrating getServerSideProps to the App Router
Consider the following implementation of getServerSideProps
:
1import { getAuth } from "@clerk/nextjs/server"23export const getServerSideProps: GetServerSideProps<PageProps> = async ({ req }) => {4const { userId } = getAuth(req);56const res = await fetch('https://api.example.com/foo', {7headers: {8Authorization: `Bearer: ${process.env.API_KEY}`9}10})11const data = await res.json()12return { props: { data } }13}14
To migrate this with as little modification as possible, we will:
getServerSideProps
into page.tsxexport const dynamic = "force-dynamic"
so the page data is refetched on every loadreq
with the App Router equivalentreq.headers
with the new headers() helperreq.cookies
with the new cookies() helperreq.url.searchParams
with the new searchParams helpergetServerSideProps
from within our Page
componentClientPage
componentHere is the end result:
page.tsx1import { auth } from "@clerk/nextjs"2import ClientPage from "./ClientPage"34export const getServerSideProps: GetServerSideProps<PageProps> = async () => {5const { userId } = auth();67const res = await fetch('https://api.example.com/foo', {8headers: {9Authorization: `Bearer: ${process.env.API_KEY}`10}11})12const data = await res.json()13return { props: { data } }14}1516export const dynamic = "force-dynamic"1718export default async function Page() {19const { props } = await getServerSideProps();20return <ClientPage {...props} />21}
Migrating getStaticPaths to the App Router
Consider the following implementation of getStaticPaths
:
1export async function getStaticPaths() {2return {3paths: [{ params: { id: '1' } }, { params: { id: '2' } }],4}5}
In the App Router, this implementation barely changes. It's simply given a new name (generateStaticParams
) and the output is transformed to something simpler. That means you can use your old implementation directly, and simply transform the output.
Here is the end result – we included an example of how it can be used in tandem with getStaticProps
:
page.tsx1import ClientPage from "./ClientPage"23export async function getStaticPaths() {4return {5paths: [{ params: { id: '1' } }, { params: { id: '2' } }],6}7}89export async function generateStaticParams() {10const staticPaths = await getStaticPaths();11return staticPaths.paths.map(x => x.params);12}1314export const getStaticProps: GetStaticProps<PageProps> = async ({ params }) => {15const res = await fetch(`https://api.example.com/foo/${params.id}`)16const data = await res.json()17return { props: { data } }18}1920export default async function Page({ params }) {21const { props } = await getStaticProps({ params });22return <ClientPage {...props} />23}
Now that data fetching is ready, we need to configure the rendering. To accomplish this:
That's it! We have already configured page.tsx to mount this file and pass props, so it should be working.
Now that your page is ready in the App Router, you can delete the old Pages Router variant.
Now that your Pages Router application is working in the App Router, it's time to start taking advantage of the App Router and React Server Components.
In particular, right now your ClientPage.tsx files are one big Client Component. Going forward, it's best to refactor this so "use client"
is used as sparingly as possible, ideally only on small components. A big Server Component importing many small Client Components will lead to less Javascript sent to the client, and a faster experience for your end user.
Start completely free for up to 10,000 monthly active users and up to 100 monthly active orgs. No credit card required.
Learn more about our transparent per-user costs to estimate how much your company could save by implementing Clerk.
The latest news and updates from Clerk, sent to your inbox.