[RFC] Rendering in Next.js (SSR, Pre-rendering, CSR, SPA)

[timneutkens]

Next.js currently has 2 modes of rendering:

• Dynamic rendering means render on demand when a request comes in.
• Pre-rendering means rendering to html at build time using next export

These modes work fine if your application only has pages of a certain type. For example zeit.co/docs is completely static. However more often than not your application is not binary, and requirements for static rendering change over time.

For example, zeit.co has a blog with static content, marketing pages, a dashboard and more. In the current model, zeit.co would be deployed with the serverless target and every page becomes a serverless function, including the blog and marketing pages that can actually be generated at build time.

Furthermore we've seen a common pattern where you'd want the dashboard to be an appshell type application that only shows the header and a loading spinner in the pre-rendered response, then after hydrating the page the data is fetched and rendered to make the application feel faster. This is generally referred to as a client-side rendered application.

Since Next.js is in control of the compilation pipeline we can decide at build time if a page will always get the same result by inferring if the page has data requirements. If it doesn't have data requirements we'll automatically render the page as a static HTML file.

When this proposal is implemented you'll be able to choose between pre-rendering and dynamic rendering on the page level.

Goals

• Provide fast by default experience
• Optimize pages that we know are always going to render the same result
• Allow usage of dynamic, static or client-side only on a per-page level
• Support client-side only applications that lazy-load data
• Powerful use-case for dashboards
• Great for marketing pages that lazy-load login / authentication state

API

This proposal doesn't need any API changes, it's mostly related to changing the semantics and internals of Next.js to export HTML in certain cases during next build.

Initially, we will cover the case where getInitialProps is not defined. Meaning that if a page doesn't have getInitialProps it is automatically exported as HTML.

// pages/about.js
export default () => <p>Hello world</p>

This is always going to render the same, so during build, we export it to an HTML file.

We might also need to detect router usage, but we won't cover that in the initial implementation as it's not as common. In this case you probably don't want to do dynamic rendering.

import { useRouter } from 'next/router'

export default () => {
  const router = useRouter()
  const { query } = router
  
  return <p>Page: {query.page}</p>
}

On the Now side of things @now/next will be updated to upload the .html files generated by the build.

[developit]

yay for more granular tradeoffs!

[amesas]

+1 for "mixed case", the app shell pattern is very common for us.

I found this after discussing an issue on Spectrum about Auth.

If the app has centralised its page auth (Or other data centric logic) into the _app.js file this breaks things quite badly.

It should also check for getInitialProps in _app.js

[PullJosh]

Can this work while using Apollo client (and other components that pull data)?

[gregberge]

I think it is not the good approach. For now, yes you can know if a page requires data or not. But tomorrow with Suspense it will not be possible to know it before rendering it.

[lfades]

@glenarama if we check for a getInitialProps in _app.js then we will never have this setup working, because _app.js is applied to every page.

@PullJosh Yes and no, if you want SSR for components that are fetching data then you'll need to make sure of including a getInitialProps in the page, even if it's empty, so the page remains dynamic, in the other side if you are okay with no having SSR and do client-side fetching of data then just don't add getInitialProps to the page and your queries/mutations will continue to work as usual.

[lfades]

@neoziro You're right, suspense will change things but it's not yet out, this is just the initial implementation.

[revskill10]

Is there any chance to extract the NextJS compiler into its own webpack plugin ?
So that users could leverage NextJS compiler into his own apps without any lock-in.
One example: A plugin to compile entry points into serverless lambdas.

[possibilities]

I like the sound of this. I wonder if there's any solution, though it would probably require additions to the api, would allow me to still have a getInitialProps, but it would be invoked on the client when exported and things would otherwise behave the same as Ssr. Perhaps I could define path globs in next config to declare whats static? I imagine I can write once and choose how to deliver it separately. A use case might be shipping a static site to humans and server rendered site to robots.

[gregberge]

@lfades the problem is that it is not possible to implement with Suspense. Except saying « we support Suspense, yes but please tell us that this page has no request » and it breaks all the flexibility of Suspense. I am just saying that including this kind of change could (in future) become a breaking change when you will have to remove it. It is just a « be careful » message.

@glenarama if we check for a getInitialProps in _app.js then we will never have this setup working, because _app.js is applied to every page.

I don't follow the reasoning - if you have a custom _app.js with a getInitialProps your injecting data into every page since it will wrap all pages. So this is the behaviour you want. If your custom _app.js doesn't have a getInitialProps your not injecting data globally so can revert to page level logic.

Personally I don't like this proposal (or the implementation) it adds a lot of dangerous edge cases to data caching which could introduce security issues down the road.