[Fizz] Postponing in the shell#27569
Merged
sebmarkbage merged 1 commit intofacebook:mainfrom Oct 23, 2023
Merged
Conversation
facebook-github-bot
added
CLA Signed
React Core Team
sebmarkbage
force-pushed
the
postponeinshell
branch
from
39d5b10 to
758a018
Compare
gnoff
approved these changes
Oct 23, 2023
Comment on lines
+2515
to
+2524
| if (boundary === null) { | ||
| segment.id = request.nextSegmentId++; | ||
| trackedPostpones.rootSlots = segment.id; | ||
| if (request.completedRootSegment !== null) { | ||
| // Postpone the root if this was a deeper segment. | ||
| request.completedRootSegment.status = POSTPONED; | ||
| } | ||
| return; | ||
| } | ||
|
|
Collaborator
There was a problem hiding this comment.
There is a reference below to
throw new Error(
'It should not be possible to possible to postpone at the root...
)
This whole boundaryKeyPath existence check can go away or if you're concerned it could still happen in maybe we just make the message clear it isn't about postponing at the root
Contributor
Author
There was a problem hiding this comment.
The "root" in that case means the very first React node before entering the first element.
I'm not sure if that's actually impossible. I think it might be if you pass in a React.lazy at the root which then postpones in the reject.
But not really related to postponing in the "shell".
github-actions bot
pushed a commit
that referenced
this pull request
Oct 23, 2023
When we postpone a prerender in the shell, we should just leave an empty prelude and resume from the root. While preserving any options passed in. Since we haven't flushed anything we can't assume we've already emitted html/body tags or any resources tracked in the resumable state. This introduces a resetResumableState function to reset anything we didn't flush. This is a bit hacky. Ideally, we probably shouldn't have tracked it as already happened until it flushed or something like that. Basically, it's like restarting the prerender with the same options and then immediately aborting. When we add the preload headers, we'd track those as preload() being emitted after the reset and so they get readded to the resumable state in that case. DiffTrain build for [05fbd1a](05fbd1a)
acdlite
added a commit
to acdlite/next.js
that referenced
this pull request
Oct 23, 2023
acdlite
added a commit
to acdlite/next.js
that referenced
this pull request
Oct 23, 2023
kodiakhq bot
pushed a commit
to vercel/next.js
that referenced
this pull request
Oct 23, 2023
React upstream changes: - facebook/react#27570 - facebook/react#27569 - facebook/react#27550 - facebook/react#27559 - facebook/react#27552 - facebook/react#27504 - facebook/react#27522 Co-authored-by: Josh Story <2716369+gnoff@users.noreply.github.com>
EdisonVan
pushed a commit
to EdisonVan/react
that referenced
this pull request
Apr 15, 2024
When we postpone a prerender in the shell, we should just leave an empty prelude and resume from the root. While preserving any options passed in. Since we haven't flushed anything we can't assume we've already emitted html/body tags or any resources tracked in the resumable state. This introduces a resetResumableState function to reset anything we didn't flush. This is a bit hacky. Ideally, we probably shouldn't have tracked it as already happened until it flushed or something like that. Basically, it's like restarting the prerender with the same options and then immediately aborting. When we add the preload headers, we'd track those as preload() being emitted after the reset and so they get readded to the resumable state in that case.
bigfootjon
pushed a commit
that referenced
this pull request
Apr 18, 2024
When we postpone a prerender in the shell, we should just leave an empty prelude and resume from the root. While preserving any options passed in. Since we haven't flushed anything we can't assume we've already emitted html/body tags or any resources tracked in the resumable state. This introduces a resetResumableState function to reset anything we didn't flush. This is a bit hacky. Ideally, we probably shouldn't have tracked it as already happened until it flushed or something like that. Basically, it's like restarting the prerender with the same options and then immediately aborting. When we add the preload headers, we'd track those as preload() being emitted after the reset and so they get readded to the resumable state in that case. DiffTrain build for commit 05fbd1a.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When we postpone a prerender in the shell, we should just leave an empty prelude and resume from the root. While preserving any options passed in.
Since we haven't flushed anything we can't assume we've already emitted html/body tags or any resources tracked in the resumable state. This introduces a resetResumableState function to reset anything we didn't flush.
This is a bit hacky. Ideally, we probably shouldn't have tracked it as already happened until it flushed or something like that.
Basically, it's like restarting the prerender with the same options and then immediately aborting. When we add the preload headers, we'd track those as preload() being emitted after the reset and so they get readded to the resumable state in that case.