feat: prep data-strategy for RSC re-use #13304
Conversation
🦋 Changeset detectedLatest commit: 6058a75 The changes in this PR will be included in the next version bump. This PR includes changesets to release 11 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| getShouldRevalidate: (routeId) => routeModules[routeId]?.shouldRevalidate, | ||
| hasClientLoader: (routeId) => !!manifest.routes[routeId]?.hasClientLoader, | ||
| hasLoader: (routeId) => !!manifest.routes[routeId]?.hasLoader, |
There was a problem hiding this comment.
Do you think we could collapse these into a single getRouteInfo function?
| unwrapSingleFetchResults: (decoded, routeId) => { | ||
| return unwrapSingleFetchTurboStreamResults(decoded, routeId); | ||
| }, |
There was a problem hiding this comment.
It bugs me we need to separate fetchAndDecode from unwrap but based on the way it's currently written we don't have a choice. I'm going to take a quick peek at a small refactor to alleviate the need to split those...
| // single fetch .data request | ||
| foundOptOutRoute = true; | ||
| } | ||
| foundOptOutRoute = true; |
There was a problem hiding this comment.
This is causing the failing E2E test - we need to short circuit either way, and then want to mark foundOptOutRoute only when hasLoader()=true
if (m.route.id in router.state.loaderData && getShouldRevalidate(m.route.id)) {
if (hasLoader(m.route.id)) {
// If we have a server loader, make sure we don't include it in the
// single fetch .data request
foundOptOutRoute = true;
}
return
}
No description provided.