Dont prefetch server loader when client loader exists #9580
Conversation
🦋 Changeset detectedLatest commit: f2bdb58 The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 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 |
| (match) => | ||
| manifest.routes[match.route.id].hasLoader && | ||
| !manifest.routes[match.route.id].hasClientLoader | ||
| ) |
There was a problem hiding this comment.
Check with @ryanflorence on this - current behavior is desired for folks who are calling await serverLoader() unconditionally because we can prefetch that so it resolves immediately. This new solution hurts those scenarios in favor of apps that conditionally call serverLoader(). Maybe we need to provide some way to enable "prefetching" (pre-executing) of client loaders - either by stashing their results into an internal cache or adding the type field to loaders we've previously discussed.
There was a problem hiding this comment.
👍 Chatted and agreed we should only prefetch module links when a client loader exists
There was a problem hiding this comment.
Would be great to have the option to prefetch/pre-execute client loaders. In my case I am using a library that has its own cache, so calling the client loader is all that's needed.
github-actions
bot
added
the
awaiting release
|
🤖 Hello there, We just published version Thanks! |
|
🤖 Hello there, We just published version Thanks! |
github-actions
bot
removed
the
awaiting release
Closes #9575