_app and getServerSideProps

[unbelivr]

Update: We’re excited to announce Next.js 13, which includes the new app/ directory (beta) with support for nested layouts, colocation of data fetching, streaming, Server Components by default, and much more.

Inside the app/ directory, there is a powerful new way to fetch data with React’s use() hook and the extended Web fetch() API. This allows you to colocate data fetching directly inside components for the most flexibility, including inside layouts.

You can leave feedback here: #41745

[willemliu]

As long as you don't implement getInitialProps, getStaticProps, getServerProps in _app. It still has the usefulness of adding persistent components for SPA apps.

[fabb]

Sorry, I don‘t understand this answer semantically. Is getServerSideProps possible in _app.js or not?

[willemliu]

Upon re-reading your question I now realize I misread it.
To get back to your Initial question of whether getServerSideProps is incompatible with _app. I haven't checked it but I assume it is incompatible in the sense that one shouldn't implement it directly in _app. I think it would be incredibly hard to implement that function. Because you need to handle all the possible pages of your entire app.

However you can use _app even though the page itself implements a getServerSideProps. You are however restricted from implementing getInitialProps there because that would conflict.

See this example: https://static-next.willemliu.now.sh

The page implementing getServerSideProps are the SSR and SSR 2 ones with _app implemented as well. Note that I was still using and old version of Nextjs and the function was still called getServerProps. I'll update it soon.

[fabb]

I haven't checked it but I assume it is incompatible in the sense that one shouldn't implement it directly in _app. I think it would be incredibly hard to implement that function. Because you need to handle all the possible pages of your entire app.

In our current app, we have implemented getInitialProps in _document.tsx, _app.tsx and all the pages. Our getInitialProps in _app.tsx calls the getInitialProps of the pages explicitly.

It would be interesting if the same is possible with getServerSideProps. If not, that would be a major limitation. We do all kinds of things in the global getInitialProps like extracting cookies and user agent for injection into Providers, fetch data for the global header, fetch user data, etc.

[MonstraG]

In our current app, we have implemented getInitialProps in _document.tsx, _app.tsx and all the pages. Our getInitialProps in _app.tsx calls the getInitialProps of the pages explicitly.

It would be interesting if the same is possible with getServerSideProps. If not, that would be a major limitation. We do all kinds of things in the global getInitialProps like extracting cookies and user agent for injection into Providers, fetch data for the global header, fetch user data, etc.

Have you ended up solving this issue in some way?

[Erixxxxxxxx]

1

[timneutkens]

Recent SSG improvements look very interesting. What will be the future of _app? Is it incompatible with new getServerSideProps?

It'll be introduced later, but we need to figure out the semantics as we really don't want getServerSideProps in _app to opt-out static generation for all pages

[timneutkens]

Yep for sure, but you shouldn't be doing that anyway as it's only the initial HTML.

[thierryMic]

@fabb and @timneutkens my apologies if this is a really stupid question but where are we supposed to use cookie-dependent code if not in get initial props?

[thierryMic]

@timneutkens i followed the with-mobx example which initialises the store in _app's getInitialProps.

1. Any thoughts on how to best achieve this now ?

2. Should we keep using getInitialProps or is there a more appropriate solution?

[jasonwilliams]

It'll be introduced later, but we need to figure out the semantics as we really don't want getServerSideProps in _app to opt-out static generation for all pages

@timneutkens are you still planning to introduce this? We can't use getServerSideProps until its in _app.tsx due to us needing to make repeated calls and checks in all of our pages. Is there an issue I should be following for updates on this?

[jonathan-hetrafi]

any updates on this?

[kristojorg]

So without getServerSideProps in _app, if I instead choose to use getInitialProps there, can I then call the page component's getServerSideProps, and or pass something (like a redux store) to that function?

[unbelivr]

There is no way to call page component’s getServerSideProps and getStaticProps in _app or HOC for now.

Next.js team can pass page’s functions along with ctx in future implementation of getServerSideProps and getStaticProps for _app, but I don’t see any possible solutions for HOCs.

[kristojorg]

Okay, thanks. I guess I'll be using getInitialProps everywhere for now.

[thierryMic]

@unbelivr I use the following piece of code in my _app and it seems to work (i.e call getServerSideProps of my pages). Are you sure that it is not supposed to work?

MyApp.getInitialProps = async appctx => {
    appctx.ctx.store = initializeStore()

    const { ctx, Component } = appctx
    const { loadAuth } = ctx.store.userStore
    const appProps = { showActions: false }

    if (typeof window === 'undefined') {
        await loadAuth(ctx.req.headers.cookie)
    }

    if (Component.getServerSideProps) {
        Object.assign(appProps, await Component.getServerSideProps(ctx))
    }

    return { pageProps: { ...appProps }, mobxstore: appctx.ctx.store }
}

[unbelivr]

@thierryMic you need to export getServerSideProps from a page.

https://nextjs.org/docs/basic-features/data-fetching#getserversideprops-server-side-rendering

[thierryMic]

@kristojorg just be careful, i have been using getInitialProps in all my pages only to find that it does not work in Safari and Firefox because of bfcaching. see getInitialProps not working with history (back button)?.

May not be a problem for you but may be worth having a look.

[nvuhung]

Any update for this issue? I need to read the data in cookie and use it for all pages. So getStaticProps or getServerSideProps in _app is very important for me.

[dsacramone]

Did you find a solution to this? I'm assuming you used getInitialProps in "_app"? Did it work? Have an example?

[jonathan-hetrafi]

yes how did you implement this otherwise?

[rudfoss]

I'm running into this same issue and I've yet to find a way to make it work. All I want is to expose req.user from express + passport so that I can read user information in the client after authentication. I want to do it for all pages so _app or _document seemed like a good fit, but it appears to be impossible(!?)

All I want is to read the req object on every request and dump some data from it to the client. I think I'm missing something obvious because that should be supremely simple IMHO.

[rudfoss]

StackOverflow question: https://stackoverflow.com/questions/62259658/nextjs-consistently-access-request-object-for-every-page
Reproduction Repo: https://github.com/rudfoss/next-server-custom-req
NextJS Discussion: #13890

[AmazingTurtle]

I'm looking into this issue as well. Looking at auth0 for example, see here:

Profile.getInitialProps = async ({ req, res }) => {
  if (typeof window === 'undefined') {
    const session = await auth0.getSession(req);
    if (!session || !session.user) {
      res.writeHead(302, {
        Location: '/api/login'
      });
      res.end();
      return;
    }
    return { user: session.user };
  }
};

this looks like a big workaround. I'd have to repeat the same getInitialProps over and over again for all the pages that require authentication. Also: what if I navigate on the client side? It would simply not fetch the user. There are dozens of workarounds that I've seen recently.

There is one big question: How to accomplish (cookie-based) authentication in nextjs with both SSR and CSR?

If I were able to get the authentication information on the server side already, pre-render the "logged-in" page and the client just keeps going with that... That'd be nice. But I haven't seen such before.

[tunesmith]

Same situation. We thought we had a solution by:

1. Putting getInitialProps in _app.tsx
2. Preventing getInitialProps from running on the client side
3. Using getServerSideProps on regular pages for whatever they needed

But it turns out - counter to what the documentation says - getInitialProps will run server-side on page transitions when transitioning to a page that hasgetServerSideProps.

So our assumption that getInitialProps will only run client-side on page transitions was false.

We also wish for a way to run something server side only on app load, and not during page transitions.

[tunesmith]

One possibility is - either in getServerSideProps or getInitialProps - test for whether the url is a data url.

if (context.req.url.startsWith('/_next/data')) {
...

[ghost]

Is there a good solution for this now?

[abergenw]

I already mentioned Next Page Layout in this discussion but I'm doing it again since I think this lib solves most of your problems.

[ghost]

I use the solution proposed by Leerob now. Call getLayout in _app and use it there. I use pageProps to get the user in my layout.

[rudfoss]

I managed to get it working by extending my _app class with this:

	public static async getInitialProps({
		ctx
	}: AppContext): Promise<AppInitialProps> {
		const req: any = ctx.req
		return {
			pageProps: {
				user: req?.user 
			}
		}
	}

This allowed me to access pageProps in the render() function which in turn allowed me to pass data from server to client. Finally I used a react context object to pass it to all my react components.

[fullStackDataSolutions]

I would Love to see an example, I have the same problem with Auth0. I can't get it to work for passing it in an Apollo Client header.

[emadabdulrahim]

@timneutkens Is there a current way of getting the user session as SSR on first page request, then subsequent page requests would be CSR since I'd store session in a Provider in _app?

Right now I have to implement getServerSideProps on every page that needs user session. Which makes my entire app SSR and routing between pages becomes slow.

[emadabdulrahim]

For better context, I'm using next-auth version 2.0

[gonzamvita]

Did you manage to solve this? Its a really common use-case.

Thanks

[dbrxnds]

Would love an update on this aswell. I feel like any web-app will have this use-case one way or another.

[Abusayid693]

Any update on this

[leerob]

@Abusayid693 Please see the update above, as well as unstable_getServerSession from NextAuth.

[AmazingTurtle]

As a workaround for the usecase regarding authentication with this issue, I have created a getServerSideProps function within a helper file:

utils/ssrHelper/authentication.js

import {auth0} from '../auth0';

const LOGIN_LOCATION = '/api/auth/login';

function mergeAuth(auth, merge, res) {
    if (!auth) {
        res.writeHead(
            307,
            {
                Location: LOGIN_LOCATION
            }
        ).end();
        return;
    }
    return {
        ...merge,
        props: {
            ...merge.props,
            auth
        }
    }
}

export async function getServerSideProps(original) {
    if (typeof original !== 'function') {
        return mergeAuth(await auth0.getSession(original.req), undefined, original.res);
    }

    return async function (context) {
        const originalReturn = original(context);
        return mergeAuth(await auth0.getSession(context.req), originalReturn, context.res);
    };
}

And on a page that needs authentication I do this:

export {getServerSideProps} from '../utils/ssrHelper/authentication';

This saves alot of boilerplate.

However, if the user is NOT logged in, a redirect can not happen on the client side when navigating between pages as of now, so you need to check the props of your page to see if auth is there, if not, return null and redirect with the next/router, so that has to be done client side sadly.

Actually this does trigger both on the client and server side. This code above will get you SSR and CSR with auth checks. It works just fine and that's nice.

[ajmnz]

TypeScript implementation (feel free to correct me if I'm doing something wrong)

interface IMerge extends GetServerSidePropsContext {
  props?: Record<string, unknown>;
}

const mergeAuth = (
  auth: string,
  merge: undefined | IMerge,
  { res }: GetServerSidePropsContext
) => {
  if (!auth) {
    res
      .writeHead(307, {
        location: "/your-login-location",
      })
      .end();
  }

  return {
    ...merge,
    props: {
      ...merge?.props,
      auth,
    },
  };
};

export const getServerSideProps = async (
  original:
    | GetServerSidePropsContext
    | ((ctx: GetServerSidePropsContext) => GetServerSidePropsContext)
) => {
  if (typeof original !== "function") {
    return mergeAuth(await authFn(original.req), undefined, original);
  }

  return async (context: GetServerSidePropsContext) => {
    const originalReturn = original(context);
    return mergeAuth(
      await authFn(context.req),
      originalReturn,
      context
    );
  };
};

[karlhorky]

a redirect can not happen on the server side as of now

Edit: It seems the RFC by Tim is the best way to go for the future (once it exists): #14890

---

@AmazingTurtle I think this is possible with the following pattern (original source):

export async function getServerSideProps(context) {
  // Status code 307 is a better 302
  context.res.writeHead(307, { Location: '/login' }).end();
}

Caveat: One downside to this approach is that on client-side navigation it throws an error (see #14547):

Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client

---

There is also a res.redirect method coming in Next.js 9.4.5:

// Only for Next.js 9.4.5+
export async function getServerSideProps(context) {
  context.res.redirect('/login');
}

---

If this works for you, can you update your comment above for anyone else who finds it?

[karlhorky]

Just confirmed this - the context.res.writeHead(307, { Location: '/login' }).end() pattern also works for client-side links.

This is on client-side navigation:

[AmazingTurtle]

What happened there? Let me check if I did something wrong.
edit: yeah I forgot the add the export on the file I was testing... :D

[karlhorky]

One downside to this approach is that on client-side navigation it throws an error:

Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client

#14547

Maybe this should actually be a bug instead...?

Will edit the original post.

[AmazingTurtle]

One downside to this approach is that on client-side navigation it throws an error:

I've seen that one but it only triggered once. When I restarted my dev server the error did not re-appear. Is there a race condition involved?

[karlhorky]

Ah, I guess the RFC by Tim is the way to go for the future: #14890

[dinesh-rdk]

So can getServerSideProps be used in _document.js?

[kmvan]

Looks not work in _app.jsx

[carlosbaraza]

In case this is useful to anyone, I found a kind of weird workaround to be able to access some request information only in SSR and avoid the automatic serialization of NextJS:

function MyApp({ getReqCookie }) {
  const cookie = getReqCookie && getReqCookie();
  // cookie is available in SSR and undefined in Client
  ...
}


MyApp.getInitialProps = async (appContext) => {
  const request = appContext?.ctx?.req;

  return {
    // workaround cause getServerSideProps is not possible in _app
    getReqCookie() {
      return request?.headers?.cookie;
    },
  };
};

[grallc]

Thanks! I was looking for this :)

[ka8725]

@carlosbaraza thanks for sharing that. But is getInitialProps called in runtime? Isn't it supposed to be called only when the site is compiled? I mean, if it's called only once on compile, it will set cookies to a static variable that will be empty always, correct?

[willemliu]

@carlosbaraza thanks for sharing that. But is getInitialProps called in runtime? Isn't it supposed to be called only when the site is compiled? I mean, if it's called only once on compile, it will set cookies to a static variable that will be empty always, correct?

getInitialProps is called on each page. getStaticProps is only called at build-time.

[CPoncet]

Thanks for this.
I was trying to get ctx directly, but for _app you need to do something like appContext.ctx.req

[Vardiak]

This is a very needed feature.
We want to hydrate the user data on first load of our SPA (with SSR), and we don't want to refetch the data at each page transition. We explored all possible ways and there is currently no way to do it...

[grallc]

J'adore Wolfy

[LucasLundJensen]

Just to give this even more attention, this is a much needed feature.
Specifically in my use case (and a few others) of reading a token to the authenticate with on the server side.

[daichi1992]

[kmvan]

This is not SSR man.

[LucasLundJensen]

This is client side data loading, not server side, has nothing to do with the topic.

[maickoldxd]

I use a simple workaround that don't need too much changes in your code

_app.jsx

`
import App from 'next/app'
import '../styles/main.scss'
import { auth } from '@/utils/auth'

const MyApp = ({ Component, pageProps }) => <Component {...pageProps} />

MyApp.getInitialProps = async (appContext) => {

if (typeof window === "undefined") {
    appContext.ctx.req.user = await auth(appContext.ctx) //return false in case of failed authentication

    if (!appContext.ctx.req.user) {
        /**
         * You should always use next js build in redirect, instead of:
         * res.writeHead(...)
         * res.end()
         * Because it will throw an error of: "You can sent headers after send to client" 
         * https://github.com/vercel/next.js/discussions/15791
         */
        appContext.ctx.req.redirect = {
            redirect: {
                permanent: false,
                destination: "/./account/login"
            }
        }
    }
    //Now you can access ctx.req.user & ctx.req.redirect in all getServerSideProps
}

const appProps = await App.getInitialProps(appContext)

return { ...appProps }

}

export default MyApp`

any getServerSide page

` export async function getServerSideProps(ctx){
//It will redirect when user is false
if (!ctx.req.user) return ctx.req.redirect

  return {
      props:{
          //if you want user props in client:
          //user:ctx.req.user
      }
  }

}
`

[Fredkr]

Any ETA for updated API? getServerSideProps in _app

[vitthalzephyr]

I also had the similar problem where I had to fetch loggedIn user details from my Auth api. I solved it by wrapping my whole app inside a context provider, then using a set function for the initialState, which will remember if it was called before and fetch user details only once. Then in my each page, wherever I require these user details, I used the context to see if details are available and call the set function if details are not available. This way I think I achieved:

Only one request to fetch user details
Because it happens from the client side, TTFB is better
I can still take advantage of getStaticProps and getServerSideProps where it is required.

[introvert]

Next-js has potential, but this makes the impulse wanting to switch to Vue.

[florianGierlichs]

isn't the new middleware stuff from Next 12 solving a lot of the issues above?

[ndavidson-manticore]

I'm not sure this was a requirement of the OP but middleware cannot pass any data in memory to the client side.

[toto1384]

You still can't pass props to the page from _middlewares and they are pretty limited because you don't have a good Response object

[abergenw]

I recently created a small lib which might solve some of the problems mentioned here.

https://github.com/abergenw/next-page-layout.

This gives you the possibility to define layouts (nested) for your pages. Each layout has its own data requirements which are either passed in as "props" from a child layout/page OR through any of the supported data fetching mechanisms (getInitialProps, getServerSideProps or getStaticProps). In addition to this there's also the possibility to do client side data fetching with "useInitialProps" in a way which prevents a waterfall effect.

So basically this lib gives you the tools to define your data requirements and (persisted) layouts on a page level without having to repeat yourself even if most of your pages use the same basics. There should be little need to mess with App using this approach.

[Emiliano-Bucci]

@abergenw Hi! Could this solve the issue of fetching global data once while keeping static rendering - when using getStaticProps? So for example, if i fetch nav items that i'll use in the header, this data is fetched once? Also, if i update one item, and data is revalidated, data is then updated only once in all pages? Or i could end up with one page with old data and another page with new/revalidated data? Thanks!

[abergenw]

@Emiliano-Bucci Next Page Layout uses the regular data fetching "hooks" provided by Nextjs but allows you to specify them per layout instead of per page like you normally would in Nextjs. This means that you can have some parent layout with getStaticProps defined (fetching and rendering your nav items) and simply "inherit" from this layout in your pages without having to:

• explicitly fetch the static props of your layout in each page AND
• explicitly render your layout with those props in each page

The pages are still regular Nextjs pages so you still need to make sure that they are rebuilt either from scratch or using incremental static regeneration whenever your nav items are updated.

Did this answer your question?

[Emiliano-Bucci]

@abergenw mmm maybe :D I need to try it, but if i use a <GlobalLayout /> inside _app, so it lives outside the nextjs <Page /> component, how this work with methods like getStaticProps? Because i believe that global application data, in case the global data is used by all layouts in an application, should be fetched inside _app (which is the main thing of this thread)

[abergenw]

@Emiliano-Bucci Like others have mentioned, adding logic/layout/data/whatever to _app is somewhat of an anti-pattern, since there's no way to opt out from that in any page. Most use-cases where you want shared data fetching and/or layouts are covered by Next Page Layout without cluttering _app. This works by assigning various properties to the page component (as a result of using makeLayout() and makeLayoutPage() which are then:

• Automatically picked up by Nextjs (getInitialProps)
• Exposed for Nextjs compatible re-exporting (getStaticProps and getServerSideProps, see example here)
• Handled by LayoutPageRenderer which you need to add to _app, see example here

So in other words, with Next Page Layout you can have one single top-level layout which is used by all your pages. This layout can be defined with getStaticProps(like here) and then in your page files you just need to re-export the "compiled" version of getStaticProps exposed by makeLayoutPage() (see here).

[sanny-io]

Any updates on this @leerob @timneutkens ?

[xucongli1989]

I am paying attention to this problem. I thought I would upgrade to 12 and use middleware to solve my problems. But I found that the middleware logic would be later than getServerSideProps, I thought it would be earlier than all requests.
So, I need to put the common data obtain logic to all the pages's getServerSideProps. So bad...

[leerob]

Update 2022: We are working on this! It will be part of the new Next.js router.

[leerob]

Happy to share the Layouts RFC is finally out: https://twitter.com/vercel/status/1528839321070993409 🥳

[darokviana]

Where?

[karlhorky]

Looks like the first half of the details are at the first blog post: https://nextjs.org/blog/layouts-rfc

And then there's some discussion over here: #37136

The features haven't been released yet (you cannot yet use them).

[mechadragon01]

Is there release date for this?

[karlhorky]

Not sure there's anything publicly announced yet, but I'm guessing it will be available in Next.js 13.

[RossMcMillan92]

My specific use-case was fetching for user data once, then having that user object available in the rest of the pages' getInitialProps AND getServerSideProps. For anyone looking for a workaround:

// pages/_app.js

App.getInitialProps = async (appContext) => {
  const { req = {}, res } = appContext.ctx
  const user = await fetchUser({ req, res })
  req.user = user
}

Then this req.user object is available wherever needed:

// pages/index.js

export const getServerSideProps = async ({ req }) => {
  req.user // fetched user from App.getInitialProps
}

[raulfdm]

Just as side note, in Next docs they say:

getInitialProps will disable Automatic Static Optimization.

https://nextjs.org/docs/api-reference/data-fetching/get-initial-props

And that can cause side-effects to your app depending how it's built

[greyes-st]

this refetches on every route change which is less than ideal

[ratasorin]

Not necessary! If you implement something like database sessions and you set an expiration date on a session, you would want to log the user out when that session expires. But you can only do that if you query your server every time the user tries to access a route! If you only check for an unexpired session when they first access your website, they can just never leave the website and remain "authenticated" and maybe even "authorized" to access every resource forever, which is a security issue that far outweighs the benefit of instantaneous navigation. In my opinion, having an optimized session storage (indexed database ~ or a kv store) should solve most of the waiting time when fetching issues!

[fredrivett]

For those wanting to share state received from a page's getServerSideProps function to global components in pages/_app.tsx, I've pieced this solution together, hopefully useful to someone:

https://stackoverflow.com/a/73234400/827129

[MartinXPN]

I'm using next-firebase-auth for authentication and ALL of the pages on my app need to have the user context. So, I would be okay with losing the static optimization as all the pages are rendered server-side either way.
I tried to use getInitialProps but it's not supported by the library.
So, I'm stuck with having to copy-paste auth code on all the pages, which also makes the server-side rendering really slow as the app needs to login the user on every page redirect. I would really prefer to have this in the _app.tsx instead which would avoid loggin in the user on every route change.

Is there any timeline on when we might have the getServerSideProps in _app.tsx?

[leerob]

Update: We’re excited to announce Next.js 13, which includes the new app/ directory (beta) with support for nested layouts, colocation of data fetching, streaming, Server Components by default, and much more.

Inside the app/ directory, there is a powerful new way to fetch data with React’s use() hook and the extended Web fetch() API. This allows you to colocate data fetching directly inside components for the most flexibility, including inside layouts.

You can leave feedback here: #41745

[toto1384]

Can you create the same /api folder within it as the pages folder??

[karlhorky]

Not yet:

While API Routes still work, they currently have to remain inside of the pages/ directory.

https://beta.nextjs.org/docs/app-directory-roadmap#caveats

[dwbruhn]

@leerob Just a heads up, I'm not sure if you meant to remove the author's question ("Recent SSG improvements...") when you edited the original post back in May:

[NishargShah]

Hello @leerob I am trying to migrate my project from pages to app and I researched a lot before migrating, this issue is the biggest issue for us right now and I am thinking that it is still not resolved, let me give you my points.

My actual purpose is to call an API of get profile on the server side and those data will pass on to my client and from my client I will decide which thing will render and get a perfect HTML for SEO. to have getServerSideProps in _app fulfill that issue, getServerSideProps will call an API and it will pass that data to the main app component. I don't think so it is fulfilled in the app directory structure as well.

• If I create a layout file with async it needs to be a server component, which means I can not load any redux or MUI providers there.
  • If I think in a way, layout will be async and I call an API there and store the data into cookies, it is also not possible ( I can not set cookies there as well ) and there is no other global file where I can put my providers.
• If I create a layout file without async it will behave as a client component ( similar to _app ) but no way to call an API.
• As per the docs, we can not pass the data from layout to page as well.

Generally, this approach is used in most projects because authentication is the very first thing we need to setup/integrate. well, above are my points that tell this issue is still not resolved, and I request you to reopen this todo.

[NishargShah]

Ohh my bad, it is resolved :)