next.js
6d33095f - fix PPR navigations when visiting route with seeded cache (#67439)

Commit
1 year ago
fix PPR navigations when visiting route with seeded cache (#67439) During SSR, we walk the component tree and pass and immediately seed the router cache with the tree. We also seed the prefetch cache for the initial route with the same tree data because navigations events will apply the data from the prefetch cache. The rationale for this is that since we already have the data, we might as well seed it in the prefetch cache, to save a server round trip later. The way we're seeding the cache introduced a bug when PPR is turned on: PPR expects that each element in `FlightDataPath` is of length 3, corresponding with: `[PrefetchedTree, SeedData, Head]`. However, we were seeding it with 4 items: `[Segment, PrefetchedTree, SeedData, Head]`. When the forked router implementation sees anything other than 3 items, it reverts back to the pre-PPR behavior, which means the data will be lazy-fetched during render rather than eagerly in the reducer. As a result, when navigating back to the page that was seeded during SSR, it wouldn't immediately apply the static parts to the UI: it'd block until the dynamic render finished. This PR also includes a small change to ensure reused tasks don’t trigger a dynamic request. A navigation test was failing because this PR fixed a bug that was causing it to hit the non-PPR behavior, which already handles this correctly. I've added an explicit test for this in PPR. I've also excluded all of the `client-cache` tests from PPR, as many of them were already failing and aren't relevant to PPR, since PPR doesn't currently make use of the `staleTime`/ cache heuristics that the regular router does.
Author
Committer
Parents
Loading