How does exactly getInitialProps works in the custom app

[ramirezsandin]

I read the following facts about getInitialProps in the documentation:

getInitialProps enables server-side rendering in a page and allows you to do initial data population, it means sending the page with the data already populated from the server.

For the initial page load, getInitialProps will run on the server only. getInitialProps will then run on the client when navigating to a different route via the next/link component or by using next/router. However, if getInitialProps is used in a custom _app.js, and the page being navigated to implements getServerSideProps, then getInitialProps will run on the server.

Adding a custom getInitialProps in your App will disable Automatic Static Optimization in pages without Static Generation.

And also in the example for custom app we have this piece of code with some useful comments:

// Only uncomment this method if you have blocking data requirements for
// every single page in your application. This disables the ability to
// perform automatic static optimization, causing every page in your app to
// be server-side rendered.
//
// MyApp.getInitialProps = async (appContext) => {
//   // calls page's `getInitialProps` and fills `appProps.pageProps`
//   const appProps = await App.getInitialProps(appContext);
//
//   return { ...appProps }
// }

So having read that, what do I want to do?:

1. Use getInitialProps in my custom app so I can read the cookies from the request.
2. Use the value of this cookie and pass it as a prop to MyApp component.
3. Insert this value into a Provider that wrap all the pages.
4. Use this value from the Provider on any Page.

As we saw before, that would fore every page to perform a server side operation (in this case the reading of a cookie), and then continue the normal behaviour.

As it was said that Automatic Static Optimization is disabled, I decided to use getStaticProps and gesServerSideProps on every page as needed.

The thing is that when getStaticProps is used, the page is again 100% statically generated and the getInitialProps that is in the custom app file, only executes client side, therefore not being able to the read the cookie and returning the value as undefined.

If it is like that, maybe the documentation is a little bit confusing in that matter and should be corrected or maybe I took something wrong for granted.

Tell me please if what I'm trying to do is possible or not, or the only way of doing that is forgetting about ssg and use ssr.

[icyJoseph]

getInitialProps is a bit wild, because, it may run, client side and server side.

When a user comes to your site, getInitialProps runs server side, after that, it runs on the client, for every SPA like page transition, unless the page it transitions to, runs getServerSideProps.

When you have getInitialProps in the _app file, you'll see this Warning:

Warning: You have opted-out of Automatic Static Optimisation due to `getInitialProps` in `pages/_app`. This does not opt-out pages with `getStaticProps`

Page Props

There's an often overlooked element in _app and that's what I am calling here, pageProps:

import type { AppProps } from "next/app";

function MyApp({ Component, pageProps }: AppProps) {
  return <Component {...pageProps} />;
}

MyApp.getInitialProps = () => {};

export default MyApp;

When a page runs, getStaticProps or getServerSideProps, not gonna talk about per page getInitialProps, then pageProps, contains those props, so that the _app can read from them and perhaps do some tweaks.

If all of your pages had getServerSideProps you could very well, use pageProps to inject the value into your provider. We might need to double check how this behaves when using SPA navigation, because the Next.js fetches the getServerSideProps result, as JSON, and injects that into the page.

Build time

Since getStaticProps runs at build time, Next.js tries to pull off an optimisation, even if there's getInitialProps on the _app page.

Why? and How? Well, it simply calls getInitialProps at build time. In some scenarios this would fail, because request objects are mocked, so, during build time, your getStaticProps page is rendered with mocked request and response objects.

---

I think in your case, getStaticProps gets in the way. If the value of the cookie really drives the application. Otherwise, if it's not necessary, but supplementary, you need to design the page with good defaults, and on mount check against an api/route, this would, sadly, produce a flash of empty data.

Depending on the use case, another solution, would be to pre-render all possible values of this cookie. For example this path: pages/pre_rendered/[cookie]/about.tsx.

You'd implement, getStaticPaths, and getStaticProps for all pages under pre_rendered. getStaticPaths would return all values of cookie, for example dark and light mode.

Then _middleware at runtime would block access to pre_rendered, and rewrite all requests going to about to instead go to /pre_rendered/dark/about, for example, if the cookie value is dark.

This wouldn't work for user driven cookies. It makes no sense to pre-render a page per user, but in such a case, we could use something like swr with fallback/initial data.

You should ask yourself: "Can I pre-render this page ahead of a user's request?" If the answer is yes, then you should choose Static Generation.

I know that in some cases, the above might be over-simplistic, because there might multiple props sources (CMS data perhaps), but then you'd need to design this without getStaticProps.

Here's an _app that uses getInitialProps to achieve a near perfect dark/light mode experience, https://github.com/NDAify/ndaify-web/blob/master/src/pages/_app.js, if you search the repo, there's no getStaticProps calls, at all.

---

Maybe you have some more ideas? Would love to keep on discussing this one.

[ramirezsandin]

Thank you for your elaborated reply @icyJoseph . Indeed I was testing this to manage to get a dark/light value from the cookie and set the theme mode before any render of the page.

I see that right now the initial flash of the default theme mode is something not ideal, but working. Having the theme mode in the URL is something I won't consider in this scenario.

Thanks for the help and the clarification.

[icyJoseph]

Just for completeness, the theme mode, wouldn't be visible to the user URL when using rewrites, they still see the regular URL.

No worries! I think this is one area where the Layouts RFC will have a huge impact. I believe anyway.

[ramirezsandin]

No worries! I think this is one area where the Layouts RFC will have a huge impact. I believe anyway.

I will have to keep an eye on that!