Example, using SSG with fallback option

This page will always be rendered statically, but the static bundle may be built either when deploying the website (AKA "pre-built"), or on-demand.

This example has been made such as the main page (at /1) is pre-built, while all other pages are built on-demand, dynamically.
Once the static page has been generated, it'll use the static version for all upcoming requests. Only the first user suffers from the waiting due to the build.
When the page hasn't been rendered before (no static build available), then we display the Loader component so that the user can see something is happening instead of a white page.

This page has not used fallback rendering (it had been generated previously).

If you use the below "previous"/"next" button, it'll make you believe pages were pre-rendered, but it's not true.
Next is so smart that it optimize this kind of stuff, using the next/link (or I18nLink) component preload pages and build them before you click on them.
If you want to check for sure if a page has been pre-rendered, you better use the "next +2" link, which uses a a which doesn't have such optimizations.

Album N°2

Title: Hold On Loosely

The request was slowed by 3101ms before being sent to the browser, to simulate a real API call.

In order to simplify things, NRN sets the isSSGFallbackInitialBuild variable, available in all pages as props.

In development mode, it is not possible to simulate fallback mode properly.
Each page refresh will completely refresh the page, any previous build will be ignored, and all page refresh will have isSSGFallbackInitialBuild: true.

Native features

Example, using SSG with fallback option

Album N°2