Top 30 SSR Interview Questions and Answers

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

1. Question 1 of 30

   What is the primary benefit of using createUseFetch over ad-hoc useFetch wrappers?

   • aIt removes the need for unplugin-vue-router and makes route generation deterministic.
   • bIt enables layouts to receive typed per-page parameters without provide/inject workarounds.
   • cIt lets you bake baseURL, interceptors, and server flags into reusable, fully typed composables that remain SSR-compatible.
   • dIt reduces dev-server route recalculation time by up to 28x when editing existing pages.
   Show the answer

   Answer: c · It lets you bake baseURL, interceptors, and server flags into reusable, fully typed composables that remain SSR-compatible.

   createUseFetch is designed to cut API boilerplate by embedding baseURL, interceptors, and server flags into reusable, fully typed composables that remain SSR-safe. Distractor B describes the Vue Router v5 upgrade's impact on dev-server performance, not fetch factories.

   Read the full bite: Nuxt 4.4 Adds Custom Fetch Factories and Router v5

2. Question 2 of 30

   When using Vue 3.5's stable reactive props destructure, what must you do to keep a destructured prop reactive when passing it to watch or a composable?

   • aConvert it to a ref using toRef()
   • bUse withDefaults as a fallback wrapper
   • cPass it directly; destructured props retain reactivity automatically
   • dWrap the variable in a getter function
   Show the answer

   Answer: d · Wrap the variable in a getter function

   Vue 3.5 requires wrapping destructured props in getters when passing them to watch or composables to preserve reactivity. Passing them directly severs the reactive link, and withDefaults is the old boilerplate this feature replaces.

   Read the full bite: Vue 3.5 cuts reactivity memory 56%, adds lazy hydration

3. Question 3 of 30

   When is Vite's low-level SSR API the most appropriate choice for a project?

   • aWhen Vite is intended to serve the entire application, including its own HTML, in production.
   • bWhen building a custom SSR framework or requiring unique server-side rendering control beyond existing plugins.
   • cTo achieve the highest possible performance for a standard web application.
   • dFor any new web application requiring server-side rendering with popular frameworks like React or Vue.
   Show the answer

   Answer: b · When building a custom SSR framework or requiring unique server-side rendering control beyond existing plugins.

   The low-level SSR API is designed for advanced scenarios like framework development or highly custom server environments, offering full control. It is explicitly advised against for standard applications using popular frameworks, which should leverage higher-level SSR plugins.

   Read the full bite: Vite's Low-Level SSR API

4. Question 4 of 30

   You have a product listing page that updates daily. Should you prerender it or SSR it? What's the main trade-off?

   • aPrerender once per day on a cron schedule to balance freshness and speed
   • bSSR for always-fresh data, but accept per-request latency and server load
   • cPrerender for instant load, but accept stale data until rebuild
   • dUse prerender with client-side polling to fetch updates after page load
   Show the answer

   Answer: a · Prerender once per day on a cron schedule to balance freshness and speed

   Daily-updated content fits a hybrid model: prerender on a cron (freshness every 24 hours) combined with instant static serve. Option C (prerender without schedule) risks stale data. Option B (pure SSR) is overkill and costly if the data doesn't change frequently. Option D adds complexity without solving the core need.

   Read the full bite: Prerendering vs SSR in SvelteKit: trade-offs?

5. Question 5 of 30

   Why does runtime CSS-in-JS specifically degrade interactivity during SSR hydration in Next.js?

   • aIt forces every component to re-fetch its CSS from the server on mount
   • bIt runs style serialization and injection on the main thread, competing with hydration
   • cIt blocks the network request for the HTML document until styles compile
   • dIt disables React's concurrent renderer entirely on the client
   Show the answer

   Answer: b · It runs style serialization and injection on the main thread, competing with hydration

   Runtime style generation executes JavaScript during render, occupying the main thread that hydration needs. It does not block the HTML request, disable concurrency, or refetch CSS over the network.

   Read the full bite: Runtime CSS-in-JS performance pitfalls in SSR Next.js

6. Question 6 of 30

   In a standard client-side React Router setup versus a Next.js App Router application, what is the critical difference in HTTP semantics when a user visits an unmatched URL?

   • aReact Router's wildcard route automatically issues an HTTP 404 status for the initial document request, while Next.js not-found.js returns HTTP 200 by default.
   • bBoth routers handle unmatched routes client-side, but React Router requires manual layout wrapping while Next.js preserves shared layouts automatically through file-system conventions.
   • cReact Router relies on implicit file-system routing to discover 404 boundaries, while Next.js App Router requires explicit wildcard route definitions in a central configuration file.
   • dNext.js App Router renders not-found.js on the server and sends a true HTTP 404 status, whereas React Router's catch-all renders in the browser and typically preserves the server's original HTTP 200 response.
   Show the answer

   Answer: d · Next.js App Router renders not-found.js on the server and sends a true HTTP 404 status, whereas React Router's catch-all renders in the browser and typically preserves the server's original HTTP 200 response.

   Next.js App Router's not-found.js convention server-renders a true HTTP 404 response, while React Router's wildcard route only manipulates the DOM client-side and leaves the initial document's HTTP 200 status unchanged. Option A is tempting because it reflects the common misconception that a React Router catch-all route affects the HTTP status code, but the framework has no built-in server-side semantics for doing so.

   Read the full bite: How do you handle 404s in React Router and Next.js App Router?

7. Question 7 of 30

   Which mechanism is primarily responsible for Server-Side Rendering (SSR) for styles preventing the 'flash of unstyled content' (FOUC)?

   • aBy caching all dynamically generated styles on the client-side for subsequent page loads.
   • bBy pre-compiling all CSS-in-JS into a separate, optimized stylesheet that loads asynchronously.
   • cBy ensuring that JavaScript executes and applies styles before the HTML content is rendered on the client.
   • dBy embedding all necessary CSS-in-JS rules directly into a <style> tag within the initial HTML document's <head>.
   Show the answer

   Answer: d · By embedding all necessary CSS-in-JS rules directly into a <style> tag within the initial HTML document's <head>.

   The correct answer is D because SSR for styles works by collecting all CSS-in-JS rules on the server and injecting them directly into the initial HTML's <head> tag. This ensures the browser receives a fully styled page immediately, avoiding the delay where HTML loads before client-side JavaScript can apply styles, which is the cause of FOUC.

   Read the full bite: SSR for Styles: Avoiding the 'Flash'

8. Question 8 of 30

   Which strategy best balances cache efficiency and personalization for SSR pages at scale?

   • aBypass CDN caching and render each request at the origin to ensure copy is always fresh
   • bCache full-page HTML per user ID at the CDN to guarantee every visitor sees the correct variant
   • cCache generic page templates with long TTLs and rely on origin database lookups during SSR to inject personalized copy
   • dUse segment-level cache keys with short TTLs and stale-while-revalidate, resolving variants at the edge
   Show the answer

   Answer: d · Use segment-level cache keys with short TTLs and stale-while-revalidate, resolving variants at the edge

   Segment-level keys prevent cache explosion while short TTLs with stale-while-revalidate shield the origin from overload; per-user caching seems precise but destroys hit rates and explodes storage costs.

   Read the full bite: Caching and performance challenges in SSR with personalized copy

9. Question 9 of 30

   A Next.js blog uses client-side data fetching to inject Open Graph tags after the page loads. When the link is shared on social media, the preview shows only the site name. What is the root cause?

   • aTwitter Card tags are required before Open Graph tags in the document head
   • bSocial crawlers read the initial HTML and do not execute client-side JavaScript
   • cOpen Graph tags must use name attributes rather than property attributes
   • dThe og:url value must match the canonical link tag exactly or previews fail
   Show the answer

   Answer: b · Social crawlers read the initial HTML and do not execute client-side JavaScript

   Social crawlers typically request raw HTML without executing JavaScript, so client-side injection leaves the meta tags invisible. Option C is a common misconception: Open Graph uses property attributes, while Twitter Cards use name attributes.

   Read the full bite: How do you dynamically populate Open Graph and Twitter Card meta tags?

10. Question 10 of 30

    You are choosing an encapsulation strategy for a design-system widget deployed on pages your team controls. What tradeoff makes Shadow DOM a worse default than build-time scoping?

    • aShadow DOM improves rendering performance by scoping style recalculation, making it preferable to build-time scoping even when the host page is trusted.
    • bBuild-time scoping offers the same encapsulation as Shadow DOM because hashed class names prevent both accidental collisions and deliberate host JavaScript mutation.
    • cShadow DOM makes external theming impossible, so build-time scoping is the only viable choice when the consuming team needs to customize tokens.
    • dShadow DOM blocks global theme inheritance and complicates SSR, whereas build-time scoping keeps the component in the global document for natural theming and trivial server rendering.
    Show the answer

    Answer: d · Shadow DOM blocks global theme inheritance and complicates SSR, whereas build-time scoping keeps the component in the global document for natural theming and trivial server rendering.

    Build-time scoping preserves the cascade and produces plain HTML that renders easily on the server, while Shadow DOM forces explicit theming contracts and client-side shadow root creation. Option B is wrong because hashed classes only stop accidental selector collisions; host JavaScript can still deliberately query and mutate internals.

    Read the full bite: Shadow DOM vs build-time scoping for third-party widgets

11. Question 11 of 30

    In Next.js pages router SSR with Redux, what is required to prevent React from discarding server markup during hydration?

    • aRedux Toolkit automatically handles state transfer across the boundary without manual serialization
    • bThe server serializes state to an escaped script tag and the client hydrates the store before ReactDOM.hydrate
    • cThe server should pass the store via props and initialize it during the root render
    • dThe client must refetch identical data after hydration to populate the store
    Show the answer

    Answer: b · The server serializes state to an escaped script tag and the client hydrates the store before ReactDOM.hydrate

    The client must bootstrap the Redux store from the server-injected payload before calling ReactDOM.hydrate so the initial render matches the server HTML exactly; initializing during render or refetching afterwards forces React to rebuild the DOM.

    Read the full bite: What is state hydration in Next.js SSR with Redux or Zustand?

12. Question 12 of 30

    When implementing SSR state hydration, which scenario represents a significant "footgun" or common pitfall?

    • aA global, singleton state store on the server leaks user-specific data between concurrent requests.
    • bThe server-rendered HTML contains stale data because the state was not properly updated.
    • cThe client's JavaScript bundle is too large, delaying interactivity after hydration.
    • dThe client attempts to hydrate with a different state management library than the server used.
    Show the answer

    Answer: a · A global, singleton state store on the server leaks user-specific data between concurrent requests.

    The card explicitly states, "The biggest footgun is defining a global, singleton store on the server; it will be shared across concurrent user requests, leaking private data." This highlights the critical need for isolated state stores per request to prevent data contamination. The other options describe general SSR or client-side issues, but not the specific state management pitfall of data leakage due to a shared server store.

    Read the full bite: SSR State Hydration: Syncing Server and Client State

13. Question 13 of 30

    What makes a render-blocking inline script the correct fix for theme flash in an SSR app?

    • aIt sets the theme attribute before first paint, since the server cannot know the client's stored preference
    • bIt eliminates the need for CSS custom properties
    • cIt allows the server to read localStorage during rendering
    • dIt defers theme application until after hydration completes
    Show the answer

    Answer: a · It sets the theme attribute before first paint, since the server cannot know the client's stored preference

    The server has no access to client preferences, so a synchronous inline script must apply the theme before paint; a post-hydration effect runs too late. The other options describe the bug, not the fix.

    Read the full bite: Preventing theme flash in SSR apps

14. Question 14 of 30

    In a Server-Side Rendered (SSR) application, what is the primary goal of hydration?

    • aTo reduce the initial HTML payload size by deferring all content rendering to the client-side JavaScript.
    • bTo enable direct manipulation of the DOM by third-party libraries without interfering with Angular's component structure.
    • cTo completely rebuild the DOM on the client-side to ensure all interactive elements function correctly.
    • dTo attach event listeners and restore application state to existing server-rendered HTML, preventing UI flicker.
    Show the answer

    Answer: d · To attach event listeners and restore application state to existing server-rendered HTML, preventing UI flicker.

    Hydration's main purpose is to reuse the server-rendered HTML by attaching event listeners and restoring state, making it interactive without re-rendering. Option C describes the problem hydration solves, not its solution, as it explicitly avoids rebuilding the DOM.

    Read the full bite: SSR Hydration: Don't Re-render, Reuse

15. Question 15 of 30

    Which scenario best justifies using dynamic rendering for a Next.js page?

    • aTo serve a company's unchanging "About Us" page to all visitors.
    • bTo display a user's personalized order history, requiring real-time data.
    • cTo reduce server load by pre-generating all possible page variations at build time.
    • dTo optimize for the fastest possible initial load time for globally accessible content.
    Show the answer

    Answer: b · To display a user's personalized order history, requiring real-time data.

    Dynamic rendering is ideal for pages with content unique to each user or requiring real-time data, as it generates the page on demand for every request. Option D is incorrect because static generation typically offers faster initial load times for globally accessible content by pre-rendering pages at build time, avoiding server-side processing per request.

    Read the full bite: Dynamic Rendering: On-Demand Pages in Next.js

16. Question 16 of 30

    What happens to server-rendered HTML once it reaches the browser in a Vue SSR app?

    • aThe browser displays it immediately without downloading any JavaScript bundles.
    • bIt remains static, since SSR outputs pure HTML with no client interactivity.
    • cVue ignores the server HTML and regenerates the entire page client-side.
    • dThe client hydrates the static markup into a fully interactive application.
    Show the answer

    Answer: d · The client hydrates the static markup into a fully interactive application.

    The card defines SSR as server HTML generation followed by client hydration. Option B is a common misconception—SSR does not eliminate client-side JavaScript; hydration is essential for interactivity.

    Read the full bite: What is SSR and what are its advantages over a client-side SPA?

17. Question 17 of 30

    Your Nuxt page renders a random greeting server-side: `Server renders: <p>Hello friend!</p>`. Client hydrates and renders `<p>Hello stranger!</p>` because Math.random() differs. What happens?

    • aHydration fails; the framework detects the mismatch and logs a warning, then re-renders
    • bThe page crashes and displays an error
    • cHydration succeeds silently; the page works but shows the server greeting
    • dHydration succeeds; the client re-renders with the new greeting
    Show the answer

    Answer: a · Hydration fails; the framework detects the mismatch and logs a warning, then re-renders

    Modern frameworks (Nuxt, SvelteKit) detect mismatches, warn in the console, and fall back to re-rendering the client version. The page works but performance is degraded (the hydration fallback causes a flash and extra work). Option D is wrong (no mismatch is detected). Option C is wrong (frameworks don't silently ignore mismatches). Option B is wrong (it doesn't crash).

    Read the full bite: Hydration: SSR HTML to interactive app?

18. Question 18 of 30

    When fetching private user data in Next.js Pages Router, why is getServerSideProps the correct choice?

    • aIt moves the data fetch to the browser so the server never handles sensitive tokens directly.
    • bIt executes on each request with access to the incoming request and user authentication cookies.
    • cIt supports incremental static regeneration to refresh private data without a full redeploy.
    • dIt pre-renders static HTML and JSON at build time that can be cached globally for fast loads.
    Show the answer

    Answer: b · It executes on each request with access to the incoming request and user authentication cookies.

    getServerSideProps runs per request and can read session cookies, ensuring private data is user-specific and never baked into shared static files. Incremental static regeneration is a tempting distractor because it still produces shared static output that any visitor could receive from the CDN.

    Read the full bite: Would you use getServerSideProps or getStaticProps for private user data?

19. Question 19 of 30

    Which statement best describes how server.ts and main.ts work together during an initial request to an Angular Universal app?

    • aserver.ts acts as a static file server like nginx, while main.ts renders the application in the browser
    • bserver.ts handles the initial request and re-renders the application on the server for every route change
    • cserver.ts renders the initial HTML and serialized TransferState, then main.ts bootstraps and hydrates the existing DOM
    • dmain.ts executes on the server to generate HTML before server.ts delivers it to the browser
    Show the answer

    Answer: c · server.ts renders the initial HTML and serialized TransferState, then main.ts bootstraps and hydrates the existing DOM

    server.ts runs on the Node.js server to render the initial HTML and TransferState, while main.ts bootstraps the browser app and hydrates that existing DOM rather than rebuilding it. Distractor D is wrong because after hydration, the Angular Router handles subsequent navigations entirely client-side without involving server.ts.

    Read the full bite: Explain server.ts and main.ts in Angular Universal

20. Question 20 of 30

    An e-commerce site has 10,000 product pages with prices that change hourly alongside user-specific account pages. Which SvelteKit approach best balances performance, freshness, and architecture simplicity?

    • aSplit the project into separate services: a static site for products and an SSR service for accounts
    • bUse adapter-vercel with ISR for product pages and dynamic SSR for account pages in the same project
    • cPrerender all pages with adapter-static and trigger a full rebuild whenever inventory updates
    • dUse pure SSR for all pages to guarantee fresh prices and personalized data on every request
    Show the answer

    Answer: b · Use adapter-vercel with ISR for product pages and dynamic SSR for account pages in the same project

    Adapter-vercel enables ISR, which serves cached product pages instantly and regenerates them in the background after deployment, avoiding hour-long rebuilds for frequent price changes while still allowing dynamic SSR for personalized account pages. Option C is tempting because SSG offers fast CDN delivery, but it would require a full rebuild every time inventory changes, making it impractical for thousands of pages that update multiple times per day.

    Read the full bite: Compare SSR, SSG, and ISR trade-offs in meta-frameworks

21. Question 21 of 30

    In Nuxt 3, useFetch in a page component fetches a product from an API. At what point is the fetch executed and data populated in the browser?

    • aFetch executes on both server and client to ensure freshness
    • bFetch executes on the client after hydration; browser shows loading spinner until complete
    • cFetch executes on the server, but data is NOT embedded in HTML; the client must fetch again
    • dFetch executes on the server during SSR, data is embedded in HTML, browser has it immediately on page load
    Show the answer

    Answer: d · Fetch executes on the server during SSR, data is embedded in HTML, browser has it immediately on page load

    useFetch executes on the server, serializes the result, and embeds it in the HTML. The browser receives a fully populated page (Option D). Option B would require a loading spinner (slow UX). Option A and D are unnecessary and slow.

    Read the full bite: Server-side data fetching in Nuxt 3?

22. Question 22 of 30

    Why is defining a shared reactive state with ref outside setup in a Nuxt module file dangerous during SSR?

    • aNuxt removes refs defined outside setup from the serialized HTML payload.
    • bIt blocks useState from registering a unique key for that state across components.
    • cThe ref loses reactivity when the client hydrates the application.
    • dThe module singleton is reused across concurrent server requests, leading to cross-user data leakage.
    Show the answer

    Answer: d · The module singleton is reused across concurrent server requests, leading to cross-user data leakage.

    Because Nuxt reuses the module singleton across requests, a global ref becomes shared mutable state that can leak data between concurrent users. Option C is tempting because SSR often involves hydration problems, but the real issue is server-side cross-request contamination, not client reactivity.

    Read the full bite: Pass server state to client in Nuxt and name the composable

23. Question 23 of 30

    What architectural behavior of Angular Universal causes memory leaks to grow with each request?

    • aAll requests share a single platform instance, so state leaks between concurrent users
    • bServer-side change detection runs continuously in the background like a browser tab
    • cEach request bootstraps a new platform that remains in the heap unless explicitly destroyed
    • dRxJS subscriptions and timers are automatically torn down when the HTTP response is sent
    Show the answer

    Answer: c · Each request bootstraps a new platform that remains in the heap unless explicitly destroyed

    Angular Universal creates a separate platform and NgModuleRef per request that stays in Node's heap if platform.destroy() or moduleRef.destroy() is not called, causing accumulation. Distractor A is wrong because platforms are per-request, not shared, so the root issue is post-request retention rather than cross-request contamination.

    Read the full bite: Angular Universal server memory leak: causes and diagnosis

24. Question 24 of 30

    For which scenario would Server-Side Rendering (SSR) typically be the most advantageous choice?

    • aAn application where minimizing server resource usage is the absolute top priority.
    • bA single-page application (SPA) where all interactivity must be available instantly.
    • cAn internal administrative dashboard with many interactive charts.
    • dA public-facing e-commerce product page requiring fast initial content display.
    Show the answer

    Answer: d · A public-facing e-commerce product page requiring fast initial content display.

    The card states SSR is ideal for public-facing content like e-commerce sites where initial load performance and SEO are critical. Options A and D are incorrect because SSR is not recommended for internal tools and it increases server load, respectively. Option B is wrong because SSR can delay full interactivity until client-side JavaScript hydrates the page.

    Read the full bite: Server-Side Rendering: Your App's First Paint Matters

25. Question 25 of 30

    What is the primary benefit of Universal Rendering compared to a traditional Single-Page Application (SPA)?

    • aIt ensures all application logic runs exclusively on the server, reducing client load.
    • bIt provides a faster initial content display and improved Search Engine Optimization.
    • cIt completely removes the need for client-side JavaScript execution.
    • dIt allows for hosting a dynamic application without requiring any server infrastructure.
    Show the answer

    Answer: b · It provides a faster initial content display and improved Search Engine Optimization.

    Universal Rendering combines the benefits of server-rendered apps and SPAs, specifically addressing the slow initial load and poor SEO of traditional SPAs by sending pre-built HTML. It does not remove client-side JavaScript, nor does it eliminate the need for a server.

    Read the full bite: Universal Rendering: Server-First, Client-Interactive

26. Question 26 of 30

    What is the primary benefit of using Nuxt's useAsyncData or useFetch for data fetching in an SSR application?

    • aIt automatically caches API responses in a global store, eliminating the need for manual state management.
    • bIt guarantees that all data fetching operations are executed exclusively on the server, improving client performance.
    • cIt prevents the client from re-fetching data that was already fetched and embedded by the server during the initial render.
    • dIt reduces the overall network requests by bundling multiple API calls into a single server-side request.
    Show the answer

    Answer: c · It prevents the client from re-fetching data that was already fetched and embedded by the server during the initial render.

    The core purpose of useAsyncData and useFetch is to solve the 'double fetch' problem by serializing server-fetched data and rehydrating it on the client, avoiding redundant network requests. While these composables manage state, they don't guarantee exclusive server-side fetching or bundle multiple distinct API calls.

    Read the full bite: Nuxt Server Data Fetching: useAsyncData & useFetch

27. Question 27 of 30

    What is the fundamental mechanism Angular's TransferState uses to avoid re-fetching data during client-side hydration in an SSR application?

    • aIt provides a server-side API endpoint from which the client can retrieve data that was pre-fetched by the server.
    • bIt establishes a direct, real-time data stream between the server and the client for all initial data.
    • cIt modifies the browser's native caching mechanisms to store server-fetched API responses.
    • dIt serializes data fetched during server rendering and embeds it as a key-value store within the initial HTML document.
    Show the answer

    Answer: d · It serializes data fetched during server rendering and embeds it as a key-value store within the initial HTML document.

    TransferState's core mechanism involves the server serializing fetched data into a key-value cache and embedding this directly into a script tag within the initial HTML. The client then retrieves this data from the HTML, preventing redundant network calls. Option A is incorrect because the client does not make a new request to an endpoint; the data is already present in the initial HTML.

    Read the full bite: Angular TransferState: Avoid Double Data Fetching in SSR

28. Question 28 of 30

    In an Angular Universal application, which task most critically requires using isPlatformBrowser to prevent server-side rendering issues?

    • aInjecting a custom service into a component's constructor.
    • bDisplaying dynamic data in a component template using interpolation.
    • cStoring user preferences in localStorage or directly manipulating the document object.
    • dMaking an HTTP GET request to fetch data from a backend API.
    Show the answer

    Answer: c · Storing user preferences in localStorage or directly manipulating the document object.

    The correct answer C involves browser-specific APIs (localStorage, document) which are unavailable in a server environment and would cause a crash during SSR without the isPlatformBrowser guard. Options A, B, and D describe standard Angular features (HTTP requests, template rendering, dependency injection) that are designed to be platform-agnostic and do not require this check.

    Read the full bite: Angular: Run Code Only on Browser or Server

29. Question 29 of 30

    For which SvelteKit page scenario would prerendering be the most effective optimization strategy?

    • aA static "About Us" page with company history and contact information.
    • bA checkout page that processes payment and updates inventory in real-time.
    • cA product catalog page whose content changes based on user authentication status.
    • dA user's personalized profile page displaying their private data.
    Show the answer

    Answer: a · A static "About Us" page with company history and contact information.

    Prerendering is ideal for pages with content that is the same for every user, such as static marketing or informational pages, as it generates HTML at build time for instant loading. Pages involving user-specific data, authentication, or real-time transactions are dynamic and should not be prerendered.

    Read the full bite: SvelteKit Prerendering: Build-Time HTML for Faster Sites

30. Question 30 of 30

    What is the primary functional difference between React's hydrateRoot and createRoot methods?

    • ahydrateRoot is used for applications requiring server-side state management, while createRoot is for client-side state only.
    • bhydrateRoot executes its rendering logic exclusively on the server, while createRoot executes exclusively in the client's browser.
    • chydrateRoot attaches interactivity to pre-existing server-rendered HTML, whereas createRoot renders the entire application into an empty DOM element.
    • dhydrateRoot is designed for static content display, while createRoot is for dynamic, interactive user interfaces.
    Show the answer

    Answer: c · hydrateRoot attaches interactivity to pre-existing server-rendered HTML, whereas createRoot renders the entire application into an empty DOM element.

    hydrateRoot is used on the client to 'wake up' and attach interactivity to HTML already rendered by the server. In contrast, createRoot is used in purely client-side rendered apps to build the entire application's DOM from scratch into an empty element.

    Read the full bite: React Hydration: Bringing Server HTML to Life