You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The prior attempt didn't quite work because resume requests don't follow the same logic that the root tasks will be zero after the preamble has been sent.
I decided to restructure things to track whether there was a shell on the resumable state. I also took the opportunity to collapse the hasBody and hasHTML booleans into a bitfield which also tracks the shell.
This is probably the right long term layering too because the fact that hoistables can't be written before the preamble is really a dom limitation not a fizz limitation. Now flushes can attempt to write hoistables every time but for dom specifically these will be noops until there is a shell.
We have to set whether there is a shell in two places. first we set it during the preamble write. This covers cases like regular renders. we can't write hoistables until we've flushed the shell so flipping the bit here is the right spot. But during a prerender we will complete the prerender and return a postponed state before we've ever started flushing. In this case we need to flip the bit during the completion of the postponed state.
In either case this produces a runtime where during render hositables always come after the preamble and during resumes hoistables only come after the preamble if the prenreder did not cotnain the shell.
0 commit comments