mirror of
https://github.com/hanzoai/next.js.git
synced 2026-09-24 17:00:51 +00:00
c2b4c0815c
This PRs unifies the caching story across the docs, making Cache Components the happy path, while still providing guidance to users in the old model. However, instead of explaining the old model and its caching layers, we've created a new guide focusing on what APIs to use and when. This follow-up PR aligns terminology across the docs: https://github.com/vercel/next.js/pull/90589 ## IA updates Getting Started section: - Improves Getting Started progression: - **Before:** CC → Fetching Data → Updating Data → Caching and Revalidating (old and new model mixed) - **After:** Fetching Data (Dynamic) → Mutating Data (Dynamic) → Caching with CC (Prerendering) → Revalidating with CC. - New: `caching.mdx` (CC-first) - Structure: - Enabling Cache Components - Data vs UI-level caching - Working with request time APIs - Passing request values to cached functions - Working with non-deterministic operations - Working with synchronous operations - How rendering works (PPR and static shell story) - New: `revalidating.mdx` (CC-first) - Explains how to use `cacheLife` and `cacheTag` Guides Section: - New: `caching-and-revalidating.mdx` (Previous Model) - For users who are not using CC, includes `fetch` options and route segment config - Moves route segment config options that don't apply to CC from API reference to this guide (for easy archiving in the future). - New: `migrating-to-cache-components.mdx` (WIP) - Del: `caching.mdx` 😌 ## Terminology We should remove caching layers from the docs. Users only needed to be exposed to them when they were configured independently, but the new CC APIs work across layers. To make it easier to review this PR, I'm consolidating terminology and fixing broken links in a new PR: https://github.com/vercel/next.js/pull/90589 --------- Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com> Co-authored-by: Joseph <[email protected]>
24 lines
1.7 KiB
Plaintext
24 lines
1.7 KiB
Plaintext
---
|
|
title: Resolving "app/ Static to Dynamic Error" in Next.js
|
|
description: This document explains the "app/ Static to Dynamic Error" in Next.js and provides potential solutions to resolve it.
|
|
---
|
|
|
|
## Why This Error Occurred
|
|
|
|
The "`app/` Static to Dynamic Error" happens when one of your routes in the `app/` directory is initially generated statically at build time, but during runtime it attempts to use dynamic server values (such as `cookies` or `headers`) either for a fallback path or while a path is being revalidated.
|
|
|
|
Currently, Next.js does not support switching between static and dynamic types during runtime, so the system throws an error.
|
|
|
|
## Possible Ways to Fix It
|
|
|
|
To resolve this issue, you have two main options:
|
|
|
|
1. Prevent the conditional use of dynamic server values that may cause the static/dynamic mode of the page to differ between build time and runtime. This ensures consistency in the rendering mode of your page.
|
|
|
|
2. Leverage the `dynamic` export to control the handling of your page. If you want to ensure your page is always handled statically, regardless of the usage of dynamic server values, you can use `export const dynamic = 'force-static'`. Conversely, if you prefer your page to always be dynamic, you can use `export const dynamic = 'force-dynamic'`, and your page won't attempt to be statically generated.
|
|
|
|
## Useful Links
|
|
|
|
- [Prerendering and Dynamic Rendering](/docs/app/getting-started/caching#how-rendering-works) - Learn more about the differences between prerendering and dynamic rendering in Next.js.
|
|
- [Request-time APIs](/docs/app/glossary#request-time-apis) - Understand more about the usage of dynamic server functions in your Next.js application.
|