How would you structure client-side data fetching in Next.js?

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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.

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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.

ONE 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.