Questions
22 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?
nextjsnextjs
Basics
Project Structure
Runtime
Compiler
SSG
SSR
CSR
Routing
Route Handlers
Route Groups
Dynamic Routes
Parallel Routes
Intercepting Routes
Middleware
Server Actions
APIS
Data Fetching
Caching
Clients
Optimisation
i18n
Security
Architecture
Deployment
Accessibility
22 / 27

Compare SWR vs React Query vs useEffect for client-side data fetching — when do you use each?

Use useEffect for simple, one-off fetches in small apps; SWR for lightweight caching and auto-revalidation in Next.js projects; React Query for complex state management needs in large-scale applications

In Client-Side Rendering (CSR), choosing the right data fetching approach significantly impacts code maintainability, user experience, and performance. The three main options—useEffect with fetch, SWR, and React Query (TanStack Query)—exist on a spectrum from manual control to fully managed server-state synchronization. useEffect provides the lowest-level access but requires manual implementation of every feature; SWR offers a lightweight, cache-first approach ideal for Next.js projects; React Query delivers comprehensive server-state management with advanced features for complex applications [citation:3][citation:7].

When to Use useEffect + fetch
  1. 1

    Simple applications with minimal data fetching requirements where adding a library would be overkill [citation:1]

  2. 2

    Learning scenarios or prototypes where you want to understand the underlying mechanics

  3. 3

    One-time data fetches that don't need caching, retries, or background updates

  4. 4

    When you need maximum control over the exact request/response flow without library abstractions [citation:6]

  5. 5

    Note: Even in these cases, be prepared to handle loading states, error states, race conditions, and memory leaks manually [citation:1][citation:6]

useEffect Pattern (Manual Implementation)

SWR (stale-while-revalidate) is developed by Vercel and designed with Next.js in mind. It's ideal for projects that need a lightweight, cache-first solution with minimal configuration. SWR automatically caches responses, deduplicates identical requests, revalidates on focus, and retries on failure—all with a simple API [citation:1][citation:5]. It's particularly well-suited for REST APIs and scenarios where you want the simplicity of hooks with built-in performance optimizations [citation:7]. The Next.js team officially recommends SWR for client-side data fetching [citation:5].

SWR Pattern (Lightweight, Cache-First)

React Query is the more comprehensive solution for applications with complex data requirements. It offers richer state management with flags like isFetching vs isLoading, built-in mutation support via useMutation, powerful devtools, and fine-grained cache control [citation:7]. It's the better choice for medium-to-large applications, GraphQL integrations, complex optimistic updates, or when you need to persist cache to localStorage. While it requires slightly more configuration than SWR, it provides unparalleled flexibility for managing server-state complexity [citation:3][citation:7].

React Query Pattern (Comprehensive State Management)

| Feature | useEffect + fetch | SWR | React Query | |---------|-------------------|-----|-------------| | Loading state | Manual | ✅ Built-in | ✅ Built-in | | Error handling | Manual | ✅ Built-in | ✅ Built-in | | Caching | None | ✅ Auto | ✅ Configurable | | Request deduplication | None | ✅ Auto | ✅ Auto | | Focus revalidation | Manual | ✅ Auto | ✅ Configurable | | Retry logic | Manual | ✅ Auto | ✅ Configurable | | Mutation support | Manual | ⚠️ Basic | ✅ Advanced | | DevTools | None | ❌ None | ✅ Rich | | Bundle size | Minimal | Small | Moderate | | SSR/Next.js integration | Manual | ✅ Excellent | ✅ Excellent |

[citation:1][citation:3][citation:7]

Choose useEffect + fetch only for the simplest cases—learning exercises, prototypes, or apps with exactly one or two data fetches that never need updates [citation:1][citation:6]. Choose SWR when you're building a Next.js application, want minimal boilerplate, need automatic caching and revalidation, and your data fetching needs are primarily GET requests [citation:5][citation:7]. Choose React Query for production applications with complex data dependencies, mutations, optimistic updates, or when you need detailed control over caching behavior and developer tooling [citation:3][citation:7]. For most production Next.js applications, SWR or React Query will save hundreds of lines of error-prone boilerplate code and provide better user experiences out of the box [citation:3].