Nextbase Cache Components

NextBase Cache Components

Load next-cache-components-optimizer for current Next.js mechanics and vercel-react-best-practices for React performance guidance.

This project enables cacheComponents and partialPrefetching in apps/web/next.config.ts.

Classify Data First

• Shared, public, deterministic data may be persisted with 'use cache' when it does not read cookies, headers, session state, or user-specific inputs.
• Personalized or authorization-sensitive data must stay dynamic and must not enter a shared cache scope.
• React cache() in src/rsc-data deduplicates work during one server render. It is not a persistent cross-request cache.

Never create an anonymous Supabase client merely to make personalized data cacheable. A different client does not change the data's privacy classification.

Composition Pattern

1. Keep the route shell and shared headings cacheable when safe.
2. Move cookie, claim, search-param, and personalized reads into a dynamic child.
3. Put a focused <Suspense> boundary directly around that dynamic child.
4. Use a stable fallback with the same broad geometry as the resolved UI.
5. Start independent reads before awaiting them and avoid serial waterfalls.

Keep 'use cache' at the narrowest scope with an explicit, reviewable data contract. Do not hide runtime APIs behind helpers called from a cached scope.

Invalidation

After a successful mutation, invalidate the exact path or tag that owns the stale shared data. Personalized dynamic reads normally refresh through navigation or re-render and should not be placed in a shared tag to force reuse.

Verification

Run the Next.js build to catch prerender/runtime boundary errors. Exercise a cold navigation, a prefetched navigation, an anonymous request, and two distinct authenticated users to prove no personalized data crosses requests.