Questions
9 of 27
1What are client components?
2How to implement client rendering in next js?
3Describe how client components are rendered.
4How to decide what part should be rendered on the server and what on the client?
5Combining client and server components
6How to render a server component in the client component?
7Discuss best approaches with client components.
8Does using 'use client' ensure that the component only renders on the client?
9Explain the full lifecycle of a CSR page in Next.js — from initial HTML delivery to interactive UI.
10What is the difference between useEffect data fetching and React Query / SWR in a CSR context?
11When would you choose CSR over SSR or SSG in a production Next.js app? Give real-world examples.
12How does React's concurrent rendering model affect CSR behaviour in Next.js 13+?
13How do you handle deeply nested Client Components without causing unnecessary re-renders?
14Explain the concept of "client component boundaries" — how do they affect the component tree?
15How would you implement optimistic UI updates in a CSR-heavy Next.js application?
16What are the challenges of using Context API at scale in a CSR and SSR? How do you solve them?
17How does next/dynamic work? How is it different from React's lazy() and Suspense?
18What is the "flash of unstyled/unloaded content" problem in CSR, and how do you prevent it?
19How do you prefetch data for CSR pages in Next.js to reduce perceived latency?
20How do useMemo and useCallback help performance in CSR components? When are they overkill?
21How do you implement skeleton screens or loading states for CSR data fetching?
22Compare SWR vs React Query vs useEffect for client-side data fetching — when do you use each?
23How do you implement infinite scrolling or pagination purely on the client side in Next.js?
24How do you handle race conditions in CSR data fetching with useEffect?
25What is the difference between client-side fetch and server actions in Next.js App Router?
26How do you cancel in-flight API requests when a component unmounts in CSR?
27How would you handle real-time data (WebSockets / SSE) in a Next.js CSR component?
09 / 27

Explain the full lifecycle of a CSR page in Next.js — from initial HTML delivery to interactive UI.

A CSR page in Next.js follows a lifecycle where the server delivers a minimal HTML shell, then JavaScript loads, executes, fetches data, and finally hydrates the page to become fully interactive

The lifecycle of a Client-Side Rendering (CSR) page in Next.js begins with the server delivering a minimal HTML skeleton, after which the browser takes over completely to render and make the page interactive. This approach prioritizes dynamic interactivity over initial content visibility, making it ideal for highly interactive applications like dashboards or authenticated experiences where SEO is less critical [citation:1][citation:5].

Phase 1: Initial Request and Server Response
  1. 1

    Browser requests the page URL from the Next.js server.

  2. 2

    Server responds with a minimal HTML document containing a root div (e.g., <div id="__next"></div>) and script tags pointing to JavaScript bundles [citation:9].

  3. 3

    No page content is present in the initial HTML — the user sees a blank screen or loading spinner if styled [citation:1][citation:3].

  4. 4

    This phase is extremely fast due to minimal server processing, but provides no visible content yet [citation:9].

Upon receiving the HTML, the browser begins downloading the JavaScript bundles referenced in the script tags. These bundles contain the React application code, including components, logic, and data-fetching libraries [citation:5]. During this phase, the browser parses and executes the JavaScript, which can cause noticeable delay — especially on slower networks or devices [citation:3]. This is why CSR pages often have slower initial load times compared to SSR or SSG [citation:1].

Basic CSR Component Example

After JavaScript executes, React renders the component tree for the first time. This initial render shows loading states, placeholders, or skeleton UI defined in the components [citation:5]. Immediately after this first render, useEffect hooks and data-fetching libraries like SWR or TanStack Query trigger API calls to fetch actual data [citation:1][citation:5]. During this period, the user sees loading indicators while data is being retrieved from backend services [citation:3].

When data fetching completes, the response data is stored in state (via useState) or cache (via SWR/TanStack Query) [citation:5]. This triggers a re-render of the component tree with the new data, replacing loading indicators with actual content. At this point, the page becomes fully populated with dynamic content [citation:1]. This re-render happens efficiently because React updates only the parts of the DOM that changed.

Phase 5: Hydration and Interactivity
  1. 1

    In a pure CSR page, "hydration" technically already happened during initial render because there was no server-rendered HTML to hydrate — the client built the DOM from scratch [citation:2][citation:6].

  2. 2

    All event handlers (onClick, onChange, etc.) are attached during the initial render, so the page is interactive as soon as the first render completes [citation:9].

  3. 3

    However, if data is still loading, interactive elements may not function as expected until their required data arrives [citation:1].

  4. 4

    This differs from SSR/SSG pages where hydration is a separate step to attach handlers to pre-rendered HTML [citation:8].

After the initial load completes, the page operates entirely on the client. User interactions trigger state changes, which cause re-renders without additional server requests (unless fetching new data) [citation:3][citation:5]. Subsequent page transitions using Next.js Link component are fast because only necessary data is fetched, and JavaScript re-renders relevant parts without full page reloads [citation:5]. This is where CSR excels — providing smooth, app-like experiences after the initial load [citation:3].

Optimized CSR with Data Fetching Libraries
  1. 1

    SWR example with automatic caching and revalidation:

    import useSWR from 'swr';
    
    export function Page() {
      const { data, error, isLoading } = useSWR('/api/data', fetcher);
      if (error) return <p>Failed to load.</p>;
      if (isLoading) return <p>Loading...</p>;
      return <p>Your Data: {data}</p>;
    }
    ``` [citation:5]
    
  2. 2

    Benefits: automatic caching, deduplication, focus revalidation, and optimistic updates [citation:5].

  3. 3

    TanStack Query provides similar capabilities with additional devtools and mutation utilities.

CSR in Next.js offers excellent interactivity and reduced server load but comes with significant trade-offs. Initial page load is slower because the browser must download, parse, and execute JavaScript before displaying content [citation:1][citation:3]. SEO is negatively impacted because search engine crawlers may not wait for JavaScript to execute and thus see empty or loading content [citation:5][citation:9]. However, for authenticated pages, dashboards, or highly interactive applications where SEO isn't a priority, CSR remains an excellent choice [citation:1]. Next.js promotes a hybrid approach where you can use CSR for some pages and SSR/SSG for others, depending on each page's requirements [citation:5][citation:7].