Cache, revalidate, and describe a page

Do not assume every server fetch is automatically cached. Current Next.js renders uncached work dynamically unless you deliberately opt data or output into caching.

With Cache Components enabled, use "use cache" for reusable cached work, cacheLife to describe its lifetime, and cacheTag to give related entries a domain name. The values passed into a cached function form part of its cache key, so accept the note ID instead of closing over mutable request state.

After a mutation, choose invalidation by meaning. updateTag gives the mutating user read-your-own-writes behavior. revalidateTag marks tagged data for refresh according to its profile, while revalidatePath invalidates a route so its next visit can regenerate. Invalidating every page hides unclear ownership and throws away useful cache work.

Without Cache Components, follow the caching model documented for the exact installed Next.js version. Do not mix examples from both systems into one app. Record the version and chosen model beside the code so a future upgrade can review the assumptions.

Use the Metadata API for titles and descriptions; dynamic pages can export generateMetadata from server code. Metadata has a freshness contract too: if it reads the same note as the page, reuse the data function and invalidation rules rather than allowing the tab title to lag behind the content.

export const metadata = {
  title: 'Field Notes',
  description: 'Short observations from the field',
}

export default function Page() {
  return <h1>Field Notes</h1>
}

Add static list metadata and dynamic note metadata, then inspect the document head after a rename. Document whether the project uses Cache Components, tag cached note data, mutate it, and verify exactly which visit observes the new value.