Questions
10 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?
10 / 27

What is the difference between useEffect data fetching and React Query / SWR in a CSR context?

useEffect provides manual, one-time data fetching with no built-in state management or caching, while React Query/SWR automate server state management with caching, revalidation, and request deduplication

In a Client-Side Rendering (CSR) context, useEffect with fetch is the most basic approach to data fetching—it works by manually triggering a request when the component mounts, storing the result in a local state, and requiring the developer to manually handle loading and error states . React Query and SWR, on the other hand, are specialized data fetching libraries built specifically to manage the complexities of server state—they provide built-in caching, automatic background revalidation, request deduplication, and comprehensive loading/error states out of the box . The core philosophical difference is that useEffect treats data fetching as a one-time side effect, while React Query/SWR treat it as a continuous synchronization problem between client and server .

useEffect Data Fetching Example
React Query / SWR Example
Key Differences at a Glance
  1. 1

    Boilerplate: useEffect requires 10-15 lines of code per fetch (state declarations, effect setup, error handling) ; React Query/SWR handle all of this in a single hook .

  2. 2

    Caching: useEffect has no built-in caching—every component mount triggers a new request even for identical data ; React Query/SWR automatically cache responses and share them across components .

  3. 3

    Request deduplication: useEffect can trigger multiple identical requests if multiple components mount simultaneously ; React Query/SWR deduplicate requests so one API call serves all components .

  4. 4

    Background revalidation: useEffect only fetches when explicitly triggered; React Query/SWR can automatically refetch on window focus, network reconnection, or set intervals to keep data fresh .

  5. 5

    Mutation support: useEffect requires manual POST/PUT handling with separate state; React Query/SWR provide useMutation hooks with built-in cache invalidation and optimistic updates .

  6. 6

    Pagination and infinite scroll: Must be implemented manually with useEffect; React Query/SWR offer dedicated hooks like useInfiniteQuery .

Server state is fundamentally different from client state—it's data you don't own, can change without your knowledge, and needs to be kept in sync with the server . Managing this manually with useEffect means handling: race conditions (responses arriving out of order), memory leaks (setting state on unmounted components), loading/error states for every fetch, caching strategies, and cache invalidation when data changes . React Query and SWR were created specifically to solve these exact problems, which is why the official Next.js documentation recommends using these libraries over raw useEffect for client-side data fetching .

useEffect with fetch is acceptable for very simple applications with one or two API calls where the extra bundle size of a library isn't justified . However, for any serious application with multiple data dependencies, user interactions that modify data, or requirements for good offline/resilient behavior, React Query or SWR provide enormous value with minimal additional complexity . The small bundle size increase is almost always worth the dramatic reduction in bug-prone manual state management code .

Share

Share via WhatsApp, X, Facebook, LinkedIn or copy link. Open Graph preview enabled.