Revalidation patterns in NextJS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when using revalidate in Next.js getStaticProps?

Consider a Next.js page using getStaticProps with revalidate: 10. What is the behavior of the page after deployment?

NextJS

export async function getStaticProps() {
  return {
    props: { time: Date.now() },
    revalidate: 10
  };
}

export default function Page({ time }) {
  return <p>Time: {time}</p>;
}

A The page is statically generated once and never updated.

B The page is regenerated at most once every 10 seconds when requested.

C The page is regenerated on every request, ignoring the 10 seconds.

D The page is regenerated exactly every 10 seconds regardless of requests.

💡 Hint

Think about how Next.js handles Incremental Static Regeneration with revalidate.

With revalidate: 10, Next.js serves the static page and regenerates it in the background at most once every 10 seconds when a request comes in. It does not regenerate on every request or on a fixed timer.

📝 Syntax

intermediate

Which Next.js data fetching method supports revalidate for automatic page updates?

Select the Next.js data fetching method that supports the revalidate option for Incremental Static Regeneration.

A getInitialProps

B getServerSideProps

C getStaticProps

D API routes

💡 Hint

Only one method generates static pages with revalidation.

getStaticProps supports revalidate to enable Incremental Static Regeneration. getServerSideProps runs on every request and does not use revalidate.

🔧 Debug

advanced

Why does a Next.js page with revalidate not update after 10 seconds?

A developer sets revalidate: 10 in getStaticProps but the page content never updates after deployment. What is the most likely cause?

NextJS

export async function getStaticProps() {
  const data = await fetch('https://api.example.com/data').then(res => res.json());
  return {
    props: { data },
    revalidate: 10
  };
}

export default function Page({ data }) {
  return <pre>{JSON.stringify(data)}</pre>;
}

A The API response is cached and does not change, so the page looks static.

B The page needs a manual rebuild to update content despite revalidate.

C The <code>revalidate</code> option must be a string, not a number.

D The <code>getStaticProps</code> function is missing a <code>fetch</code> call.

💡 Hint

Consider what happens if the data source does not change.

If the API data does not change, the regenerated page will look the same, so it appears not to update. The revalidate option is correctly used as a number.

🧠 Conceptual

advanced

How does Next.js handle concurrent requests during page revalidation?

When multiple users request a page that is due for revalidation, how does Next.js handle regenerating the page?

A Next.js serves the old page to all requests and regenerates the page once in the background.

B Next.js returns an error to all requests during regeneration.

C Next.js blocks all requests until the page is regenerated.

D Next.js regenerates the page multiple times concurrently for each request.

💡 Hint

Think about user experience during regeneration.

Next.js serves the existing static page to all requests while regenerating the page once in the background to avoid delays or errors.

❓ state_output

expert

What is the output of this Next.js page with revalidate and dynamic data?

Given the code below, what will the page display if requested twice with a 15-second gap?

NextJS

export async function getStaticProps() {
  return {
    props: { timestamp: Date.now() },
    revalidate: 10
  };
}

export default function Page({ timestamp }) {
  return <p>Timestamp: {timestamp}</p>;
}

A The page throws an error because Date.now() is used in getStaticProps.

B Both requests show the same timestamp from the first build.

C Both requests show the current time at request, ignoring revalidate.

D The first request shows the initial timestamp; the second shows a new timestamp updated after 10 seconds.

💡 Hint

Remember how revalidate controls regeneration timing.

The first request serves the static page with the initial timestamp. After 10 seconds, the next request triggers regeneration, so the second request shows an updated timestamp.