Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[Flight] Refactor the Render Loop to Behave More Like Fizz (#28065)
This refactors the Flight render loop to behave more like Fizz with similar naming conventions. So it's easier to apply similar techniques across both. This is not necessarily better/faster - at least not yet. This doesn't yet implement serialization by writing segments to chunks but we probably should do that since the built-in parts that `JSON.stringify` gets us isn't really much anymore (except serializing strings). When we switch to that it probably makes sense for the whole thing to be recursive. Right now it's not technically fully recursive because each recursive render returns the next JSON value to encode. So it's kind of like a trampoline. This means we can't have many contextual things on the stack. It needs to use the Server Context `__POP` trick. However, it does work for things that are contextual only for one sequence of server component abstractions in a row. Since those are now recursive. An interesting observation here is that `renderModel` means that anything can suspend while still serializing the outer siblings. Typically only Lazy or Components would suspend but in principle a Proxy can suspend/postpone too and now that is left serialized by reference to a future value. It's only if the thing that we rendered was something that can reduce to Lazy e.g. an Element that we can serialize it as a lazy. Similarly to how Suspense boundaries in Fizz can catch errors, anything that can be reduced to Lazy can also catch an error rather than bubbling it. It only errors when the Lazy resolves. Unlike Suspense boundaries though, those things don't render anything so they're otherwise going to use the destructive form. To ensure that throwing in an Element can reuse the current task, this must be handled by `renderModel`, not for example `renderElement`.
- Loading branch information