When and how are React lifecycle methods called in the NextJS SSR process?

Question

This is a simple question that almost certainly is answered in the NextJS documentation somewhere, but after looking (as well as googling for some writeup about it) I can't find it.

As I understand it, NextJS works thusly:

• If you arrive at your app from an 'external' URL, that is, not through a Link, then the page is SSR'd, and NextJS sends a combo of HTML with JS (NextJS framework, React, etc) to the browser. This HTML is produced through React, on the server.

• During the SSR getInitialPropsis called on the server and (I assume) passes initial data down to the SSR process through props

• Then React lifecycle methods are called (componentDidMount /useEffect). The application still has access to initial data through props. As I understand it, these lifecycle methods are called on the client -- that's what my console.log tells me -- and thus you can be guaranteed access to things like localStorage.

• But does this imply that is there a second render on the client side after the original SSR, that is, the original HTML delivered is replaced by the SPA?

• Or does the original SSR content remain, but NextJS somehow calls the React lifecycle methods "directly"?

Part of the issue is that I have zero knowledge of how React works internally -- what relation painting the screen and lifecycle methods have with each other.

I'm trying to understand how NextJS works -- what exactly is the flow, and how NextJS' SSR and React work together, and what happens when and where.

Any help much appreciated!

Answer 1

But does this imply that is there a second render on the client-side after the original SSR, that is, the original HTML delivered is replaced by the SPA?

What you're describing is what's called the "rehydration" process. Next will return the server-side content and then rehydrate on the client-side through effects (e.g., useEffect) or data fetching client-side (e.g., SWR).

I would recommend watching this video for a more detailed explanation from Tim, the lead maintainer of Next.js.