-
Notifications
You must be signed in to change notification settings - Fork 47.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Fizz] Postponing in the shell #27569
Conversation
39d5b10
to
758a018
Compare
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; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah ty
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)
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 <[email protected]>
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.
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.
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.