What is __N_SSG?

[Vadorequest]

In _app:render, I've noticed the __N_SSG variable which is only present when the page is served statically (using SSG)

Is it something not meant to be used? What does it mean? Can we rely on it anyhow?

[Timer]

This is a private field (mind the double underscore) used by Next.js to know the page needs its static data fetched on client-side transition.

You cannot rely on it, as we've already renamed it a few times and do not plan on making it a public API. We may even remove it in the future.

[Vadorequest]

@Timer Does __N_SSP stand for "Pre-rendering"?

I'm asking because I'm trying to build something similar, meant to help developers to know whether a page was served using static/dynamic rendering. It's non-trivial considering all possible use-cases:

• Page served dynamically (getStaticProps, server build, when working locally)
• Page served dynamically (getStaticProps, client re-render, when working locally)
• Page served statically (getStaticProps, static bundle, client-side)
• Page served dynamically (getInitialProps, callable from server or client, must use universal code)
• Page served dynamically (getServerSideProps, callable from server or client-through-proxy-api (is that what you call pre-rendering?))

There are many possibilities, and it's important to make it clear what rendering mode is being used because some business behaviours could depend on it. (e.g: Nav bar with "Profile" section that is shared by many pages (SSG/SSR), where SSR should render it from server, but SSG should render it from client)

Why don't you consider making it a public API? Is it too unstable or subject to changes yet? Is it planned in the future?

How would you advise to design such field? I'm thinking about the following design:

• rendering
  • mode: SSG|SSR - Rendering mode
  • origin: browser|server - Origin of the request/page load
  • servedBy: 'browser|server` - What actually served the page

Which would translate to those potential combinations:

• { mode: 'SSG', origin: 'server', servedBy: 'server' } - Page served dynamically (getStaticProps, server build, when working locally)
• { mode: 'SSG', origin: 'server', servedBy: 'browser' } - Page served dynamically (getStaticProps, client re-render, when working locally)
• { mode: 'SSG', origin: 'browser', servedBy: 'browser'} - Page served statically (getStaticProps, static bundle, client-side)
• { mode: 'SSR', origin: 'server', servedBy: 'server'} - Page served dynamically (getInitialProps, server initial render)
• { mode: 'SSR', origin: 'browser', servedBy: 'browser'} - Page served dynamically (getInitialProps, client re-render/render (CSR))
• { mode: 'SSR' (SSP ?), origin: 'server', servedBy: 'server'} - Page served dynamically (getServerSideProps, called from server directly (e.g: page refresh)
• { mode: 'SSR' (SSP ?), origin: 'browser', servedBy: 'server'} - Page served dynamically (getServerSideProps, called from browser and proxied through API (e.g: client-side navigation to a page using getServerSideProps)

This gets complicated, and it may get "worse" with iSSG/SSG-with-fallback from a developer standpoint (harder to reason about, system needs to be observable)

Does the above design make sense? Does Next.js uses something similar internally?

[Timer]

SSP stands for server-side props. However, to reiterate above, please do not rely on this field.
Now that you've pointed out that it accidentally leaked into props (where it shouldn't be), we're probably going to fix it (remove it).

I'd be happy to fence an official RFC on what a public API would look like for this, if you could put one together.

[Vadorequest]

Thanks for the clarification. I understand it shouldn't be used, hence the above attempt to clarify the API.

Does the above mode, origin and servedBy concepts make sense? I believe those 3 are necessary to fully understand what's going on, but I'd love some feedback on this. (Variable names don't matter much at this point)

[Vadorequest]

@Timer For clarification, do you mean you'd like I create a RFC discussion about this topic? I thought those had to be "official" (led by core members).

I'd gladly work on that topic, but currently unsure about how I can help exactly.

[Vadorequest]

@Timer Ping 👆