THN Interview Prep

State, SSR & hydration boundaries

Core details

Ownership map:

SlicePersisted whereHydration implication
URLRoutingshareable deterministic server render
Server query cacheDehydrated payload vs client fetchduplication / drift risk
Local UI ephemeralRAMmust not collide with SSR HTML
Global storememoryhydrate carefully—single graph truth

Classic mismatch classes:

  1. Non-deterministic render (Date.now(), random IDs) diverging SSR vs client.
  2. Environment globals referenced during SSR (window without guard).
  3. Double-fetch ignoring dehydrated state.
  4. Timezone/locale skew between server locale default and browser.

Streaming / partial SSR: islands split server-only vs interactive components—articulate hydration cost vs TTFB improvement explicitly.

Understanding

Hydration merges two worlds authored separately: declarative SSR snapshot + imperative client awakening. Divergence manifests as patched DOM explosions, flashes, hydration warnings—not merely cosmetic glitches—they signal incorrect mental model about source of truth. Duplicating server query results into client caches without aligning keys/descriptors produces subtle staleness arcs.

Eliminating divergence often means narrowing boundary surface: deterministic rendering, delaying client APIs, aligning serialization schema.

Senior understanding

Expect interview follow-ups bridging product:

ProbeAim
“Single layout shift acceptable?”connect contract SLO UX
Progressive enhancement acceptable?define graceful degradation tiers
Securityminimize serialized sensitive fields

Staff angle: treat serialized payload like an API migration—coordinate deploy ordering when shapes change.

Operational angle: lightweight client telemetry for hydration warnings and reconciliation mismatches catches silent regressions early.

Diagram

Loading diagram…

See also

Last updated on

Spotted something unclear or wrong on this page?

On this page