Avoid calling shouldRevalidate on interrupted initial load fetchers #10623
Conversation
🦋 Changeset detectedLatest commit: 0491082 The changes in this PR will be included in the next version bump. This PR includes changesets to release 5 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 |
| if (fetchControllers.has(rf.key)) { | ||
| abortFetcher(rf.key); | ||
| } |
There was a problem hiding this comment.
When we're about to reload/revalidate a fetcher.load call, ensure we abort any in-progress loads before we overwrite them with a new controller
| let isPerformingInitialLoad = | ||
| fetcher && | ||
| fetcher.state !== "idle" && | ||
| fetcher.data === undefined && | ||
| // If a fetcher.load redirected then it'll be "loading" without any data | ||
| // so ensure we're not processing the redirect from this fetcher | ||
| !fetchRedirectIds.has(key); |
There was a problem hiding this comment.
This is the net new condition, otherwise this code just combines the if blocks for cancelledFetcherLoads/isPerformingInitialLoad/shouldRevalidate since they all populate the same object into revalidatingFetchers.
|
🤖 Hello there, We just published version Thanks! |
|
🤖 Hello there, We just published version Thanks! |
If an initial
fetcher.loadis interrupted by a navigation, we should not try to callshouldRevalidatefor the interrupted fetcher since it still performing the initial load and therefore it's not a revalidation. This is specifically crucial in Remix apps where the "load" also encompasses loading the JS route module, so until the first one completes we don't even have ashouldRevalidateimplementation to call.Also ensures we properly abort in-progress
fetcher.loadcalls that are re-loaded in this manner.Closes #10473