What is state hydration in Next.js SSR with Redux or Zustand?

WHAT THIS TESTS: The interviewer wants to know if you understand hydration as a specific reconciliation phase rather than a generic loading concept. They are probing your knowledge of the server-client boundary in Next.js pages router SSR, specifically how imperative state containers like Redux or Zustand interact with React's declarative tree. Senior candidates should demonstrate awareness of serialization constraints, timing guarantees, and security implications when transferring state across the wire.

A GOOD ANSWER COVERS: First, define hydration accurately: it is the process where React takes existing server-rendered HTML and attaches event listeners and component state without destroying the DOM. Second, describe the plumbing: on the server, after fetching data and populating the store, you serialize that state to a string and inject it into the HTML response inside a script tag, conventionally a global variable such as window.INITIAL_STATE. Third, explain the client bootstrap: before calling ReactDOM.hydrate, the client reads that global variable and uses it as the preloaded state for createStore or Zustand's create function so the first client render matches the server snapshot exactly. Fourth, list the pitfalls: HTML mismatches if the client store initializes differently than the server, which forces React to throw away the server markup and fully re-render; XSS vulnerabilities if the serialized JSON is not escaped to prevent script tag injection; and crashes when state contains non-serializable values like functions, Dates, or class instances that do not survive JSON.stringify. Fifth, mention that in the App Router, this pattern changes because Server Components run on the server only and do not hydrate, so shared state requires different patterns like passing props or using cache.

COMMON WRONG ANSWERS: A major red flag is describing hydration as simply fetching data on the client after the page loads. Another is suggesting the client should refetch identical data instead of reusing the server payload, which defeats the purpose of SSR. Candidates often forget to mention XSS escaping, which is critical because an attacker-controlled field rendered into an unescaped JSON blob can execute arbitrary code. Some also claim that Redux state can contain anything because it is client-side, ignoring that the initial state must cross the serialization boundary.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle a user-specific token or secret that exists in the server store but should not be sent to the client. They might also ask about the App Router and why this hydration problem largely disappears with Server Components. Another follow-up is how you would detect and debug a hydration mismatch in production, or what tools like Redux Toolkit or Zustand's persist middleware do to help or hurt this flow.

ONE CONCRETE EXAMPLE: Imagine a Next.js pages router app using Redux Toolkit. In getServerSideProps, you fetch a list of products and dispatch them into the store. You then return props containing the serialized store state. In your custom _document.js or via a script in _app.js, you render a script tag that sets window.PRELOADED_STATE to the JSON string, but you first escape any closing script sequences to prevent injection. In the browser, your store configuration file checks for window.PRELOADED_STATE and passes it as the preloadedState argument to configureStore. If you instead initialize the client store with an empty array and then dispatch the products after hydration, the initial client render will show an empty list while the server HTML shows products, causing React to detect a mismatch and wipe the DOM.