How do you handle user-specific content on a getStaticProps page?

WHAT THIS TESTS: This tests your grasp of the build-time versus request-time boundary in Next.js Pages Router. Specifically, getStaticProps executes during static generation, which happens at build time and has no access to the incoming request object, cookies, headers, or session. The interviewer wants to know if you can architect a page that remains mostly static for performance and SEO while still supporting personalized interactivity without rebuilding the page for every user.

A GOOD ANSWER COVERS: A good answer hits four things in order. First, explicitly state that getStaticProps runs without request context, so user identity and cookies are unavailable at build time. Second, describe serving a static generic shell from the CDN or edge, ensuring fast Time to First Byte and good cacheability. Third, explain hydrating user-specific state on the client after mount, typically with useEffect or a data-fetching library like SWR or React Query, fetching from an API route that does have access to cookies and session. Fourth, mention UX patterns such as skeleton loaders, optimistic updates, or defaulting the button to an unliked state to avoid layout shift and perceived jank.

COMMON WRONG ANSWERS: Common wrong answers include suggesting getStaticProps can accept headers or cookies directly, proposing getServerSideProps for the entire page just to render a single like button, or recommending Incremental Static Regeneration per user, which would explode the cache and defeat the purpose of static generation. Another red flag is saying you can pass the user ID as a query parameter to getStaticProps; query parameters are available to getServerSideProps but not to the static generation context in the same way, and doing so would create a cache entry per user.

LIKELY FOLLOW-UPS: Interviewers often follow up by asking how to avoid a flash of unliked content before the client fetch completes, how to handle SEO for user-specific metadata, or when you would actually choose getServerSideProps over this hybrid approach. They may also ask about caching strategies for the client-side fetch, how to deduplicate requests across components, or how to handle authenticated API routes securely without exposing tokens.

ONE CONCRETE EXAMPLE: Imagine a blog post page with thousands of views. getStaticProps fetches the post title, body, and author at build time and returns them as props. The page renders immediately from the CDN with the post and a generic like button in a neutral state. Inside a client component, a useEffect hook calls POST /api/likes/status with credentials included. The API route reads the session cookie, queries the database, and returns the liked state. The button then updates to show the filled heart. If the fetch takes two hundred milliseconds, the button shows a subtle skeleton or spinner; if the user clicks like before the fetch resolves, you apply an optimistic update and sync with the server afterward.