How would you structure client-side data fetching in Next.js?
Tests when client fetching is needed in Next.js App Router. A strong answer marks the component with "use client" and fetches in useEffect or via SWR. It also handles loading, error, and race conditions.
What's really being asked
This tests your understanding of runtime boundaries in the Next.js App Router. The interviewer wants to know if you can identify when data must be fetched in the browser rather than on the server, and whether you understand the architectural implications of using Client Components, state management, and request deduplication.
The full answer
First, the component must be marked with the "use client" directive because data fetching that depends on the browser environment or user session cannot happen during server rendering. Second, you should fetch inside a useEffect hook with native fetch, or better yet, use a dedicated data fetching library like SWR or TanStack Query. These libraries handle caching, deduplication, background revalidation, and race condition prevention automatically. Third, you must handle all UI states explicitly: loading skeletons or spinners, error boundaries or inline error messages, and empty states. Fourth, mention cleanup: aborting fetch requests if the component unmounts to prevent memory leaks and state updates on unmounted components.
The mistakes people make
A major red flag is suggesting a fetch directly inside a Server Component for user-specific data that is only available after hydration. Another is using useEffect without a cleanup function or without handling the mounted flag, leading to race conditions and memory leaks. Candidates also stumble by fetching in every child component without lifting or deduplicating requests, causing a waterfall of network calls. Saying you would use getServerSideProps or the pages router patterns without acknowledging the App Router model is also a sign of outdated knowledge.
What usually comes next
The interviewer might ask how you would avoid a loading spinner if the data is needed immediately, which leads to discussion of prefetching, server rendering the shell, or streaming. They could ask how you handle authentication tokens that are only available in the browser, or how you would share fetched data across multiple components without prop drilling. Another follow-up is how to test such a component, which should involve mocking the fetch or the hook provider.
A concrete example
Imagine a dashboard greeting that shows the user's display name from an API endpoint that requires a client-side JWT. You would create a UserGreeting component with "use client" at the top. Inside, you would use SWR with a fetcher function that reads the token from a secure httpOnly cookie via an API route or from memory, then call the user profile endpoint. While the request is in flight, you render a skeleton text block. If the request fails, you show a fallback message. If it succeeds, you render the greeting. Because SWR caches by key, navigating away and back does not trigger a duplicate request.
Interview question
Which approach correctly fetches client-specific user data in a Next.js App Router component while avoiding race conditions?
- a.Use getServerSideProps in a page.js file within the app directory to fetch data at request time
- b.Mark the component with "use client", fetch with SWR or useEffect with cleanup, and handle loading and error UI statesCorrect
- c.Fetch inside a Server Component using localStorage to read the auth token during render
- d.Use "use client" and fetch in useEffect without cleanup, relying on Strict Mode to prevent memory leaks
Why? this is the answer
Client Components are required when data depends on browser-only APIs like localStorage or user sessions, and using SWR or useEffect with cleanup prevents race conditions and memory leaks. Option C is wrong because Server Components run on the server and cannot access browser APIs during rendering.
Just read this? Test yourself on what you have been reading.
Read the original → nextjs.org
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on react — each one lists the topics its interview covers.
See open roles