mirror of
https://github.com/vercel/next.js.git
synced 2026-09-20 02:25:18 +08:00
Andrew Clark
04b8a9d218
The head (metadata) is already fetched and cached like a page segment, keyed at its own metadata vary path, but the render tree stored it as two extra fields on the page node's CacheNode. Every navigation function threaded the seed head and the metadata vary path down to every child so the page node could resolve it, using a copy of the segment resolution logic that only ran for pages, and the BFCache faked a head-only entry by writing the head into a segment entry's rsc slot. Store the head as an ordinary CacheNode instead, on a one-node route tree kept beside the route's render tree. A new RootRouteTree type names this pair: it is what a server response decodes to, what the router state holds, and what a navigation produces. The head node is created by the same createRenderTreeForSegment as page segments, so the BFCache, hydration, history traversal, cache read and deferred-data paths apply to it unchanged, and startPPRNavigation returns the tree and head tasks together. The Head component reads the node directly, so findHeadInCache is gone. The head is reused on the same terms as the page it belongs to: an unchanged vary path and not a same-page navigation. When every segment is cached but the head is not, the navigation sends the server's metadata-only request instead of refetching the page and discarding it, and a response that carries no head is treated as a mismatch like a missing segment. The head's BFCache entry also has its stale time updated from dynamic responses, which never happened before.