Optimistic routing: client-side route prediction#88965
Conversation
Tests Passed |
| initialFlightData: initialRSCPayload.f, | ||
| initialCanonicalUrlParts: initialRSCPayload.c, | ||
| initialRenderedSearch: initialRSCPayload.q, | ||
| initialCouldBeIntercepted: initialRSCPayload.i, |
There was a problem hiding this comment.
This is intentional. The prerendered field (also known as S in the RSC payload) indicates whether the response was prerendered, which is exactly the information we need to determine isPPREnabled for this particular route.
For server actions specifically, we use isPrerender because action responses can be static (when the action redirects to a prerendered page). The naming difference reflects the context: prerendered is the RSC payload field name, while isPPREnabled is what the known route system uses to track whether PPR applies to that route pattern.
| size: 0, | ||
| staleAt: template.staleAt, | ||
| version: template.version, | ||
| } |
There was a problem hiding this comment.
This is working as designed. The synthetic entries are intentionally created to enable instant loading states for unprefetched routes that match a known pattern.
When we navigate to an unprefetched route (e.g., /blog/post-2 with prefetch={false}), the synthetic entry allows us to immediately show the loading boundary with the correct params ("Loading post-2...") before any server response arrives. This is the core user-facing benefit of route prediction.
The actual segment data will be fetched during navigation and will replace the synthetic entry's template. The renderedSegments field in the synthetic entry is empty, so segment cache lookups will miss and trigger fresh fetches. The template itself (route structure, loading boundaries) is reused since it's the same for all param values of the same route pattern.
a036b75 to
43903b0
Compare
Adds optimistic routing, enabling the client to predict route structure for URLs that haven't been prefetched yet. When navigating to a URL like /blog/post-2, if we've previously learned the pattern from /blog/post-1, we can predict the route structure without waiting for a server response. The client learns route patterns from server responses and builds a trie indexed by URL parts. When a cache miss occurs, we check if the URL matches a known pattern. If so, we create a synthetic cache entry from the template, allowing immediate rendering of loading boundaries. Static siblings (like /blog/featured alongside /blog/[slug]) are tracked to avoid incorrect predictions - we only predict dynamic routes when we're confident no static sibling matches.
43903b0 to
9f45cb3
Compare
Based on:
Adds optimistic routing, enabling the client to predict route structure for URLs that haven't been prefetched yet. When navigating to a URL like /blog/post-2, if we've previously learned the pattern from /blog/post-1, we can predict the route structure without waiting for a server response.
The client learns route patterns from server responses and builds a trie indexed by URL parts. When a cache miss occurs, we check if the URL matches a known pattern. If so, we create a synthetic cache entry from the template, allowing immediate rendering of loading boundaries.
Static siblings (like /blog/featured alongside /blog/[slug]) are tracked to avoid incorrect predictions — we only predict dynamic routes when we're confident no static sibling matches.