rsnext/test/e2e/app-dir/dynamic-interception-route-revalidate
Zack Tanner d2548b5435
fix router revalidation behavior for dynamic interception routes (#63768)
### What
When calling `revalidatePath` or `revalidateTag` in a server action for
an intercepted route with dynamic segments, the page would do a full
browser refresh.

### Why
When constructing rewrites for interception routes, the route params
leading up to the interception route are "voided" with a
`__NEXT_EMPTY_PARAM__` demarcation. When it comes time to look up the
values for these dynamic segments, since the params aren't going to be
part of the URL, they get matched via `FlightRouterState`
([ref](d67d658ce7/packages/next/src/server/app-render/app-render.tsx (L153-L201))).

The `shouldProvideFlightRouterState` variable only passes it through for
RSC requests; however, since the server action will perform the action &
return the flight data in a single pass, that means the updated tree
from the server action isn't going to receive the `FlightRouterState`
when constructing the new tree. This means the old tree will have a
`["locale", "en", "d"]` segment, and the new tree from the server action
will have `"[locale]"`. When the router detects this kind of segment
mismatch, it assumes the user navigated to a new root layout, and
triggers an MPA navigation.

### How
This unconditionally provides the `FlightRouterState` to
`makeGetDynamicParamFromSegment` so that it can properly extract dynamic
params for interception routes. We currently enforce interception routes
to be dynamic due to this `FlightRouterState` dependency.

Fixes #59796
Closes NEXT-2079
2024-03-28 13:35:22 +00:00
..
app/[locale] fix router revalidation behavior for dynamic interception routes (#63768) 2024-03-28 13:35:22 +00:00
dynamic-interception-route-revalidate.test.ts fix router revalidation behavior for dynamic interception routes (#63768) 2024-03-28 13:35:22 +00:00
next.config.js fix router revalidation behavior for dynamic interception routes (#63768) 2024-03-28 13:35:22 +00:00