Create a root task for every Flight response #29673
Conversation
This lets any element created from the server, to bottom out with a client "owner" which is the creator of the Flight request. This could be a Server Action being invoked or a router. This is similar to how a client element bottoms out in the creator of the root element without an owner. E.g. where the root app element was created. Without this, we inherit the task of whatever is currently executing when we're parsing which can be misleading.
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
facebook-github-bot
added
the
React Core Team
|
I like that we now see the client/server boundaries in both directions! 👍 If not for this improvement, I would have suggested as an alternative to #29669, and similar to #28403, that we maybe prefix the server component tasks with |
|
If I ignore list the bootstrapping scripts then the 
Ignore listing the sourceURL doesn't seem to work but it'll probably work with source maps. If I ignore list it server side the 
This is more like what it'd look like in Next.js unless the element is rooted in a Server Action. |
There was a problem hiding this comment.
This is more like what it'd look like in Next.js unless the element is rooted in a Server Action.
This sounds like an argument for prefixing? Especially on larger stacks it is easy to miss the "use client" and "use server" doors. But then it may be too chatty with prefixing. It doesn't block this PR and we probably just need some feedback from field usage anyway.
|
The environment name is a little tricky regardless because the way we want to set it up, it can change in the middle. So the environment name associated with a Server Component is really the environment that it entered with but it can change half way through and different stack frames in the middle. Which is likely not what someone would assume. Especially if it changes immediately inside and 99% of the code is in the other env. One way would be to annotate the stack frames rather than the tasks but that's tricky with source maps because the name should actually be picked up from the source map in that case and not the running fake function. |
This lets any element created from the server, to bottom out with a client "owner" which is the creator of the Flight request. This could be a Server Action being invoked or a router. This is similar to how a client element bottoms out in the creator of the root element without an owner. E.g. where the root app element was created. Without this, we inherit the task of whatever is currently executing when we're parsing which can be misleading. Before: <img width="507" alt="Screenshot 2024-05-30 at 12 06 57 PM" src="https://github.com/facebook/react/assets/63648/e234db7e-67f7-404c-958a-5c5500ffdf1f"> After: <img width="555" alt="Screenshot 2024-05-30 at 4 59 04 PM" src="https://github.com/facebook/react/assets/63648/8ba6acb4-2ffd-49d4-bd44-08228ad4200e"> The before/after doesn't show much of a difference here but that's just because our Flight parsing loop is an async, which maybe it shouldn't be because it can be unnecessarily deep, and it creates a hidden line for every loop. That's what the `Promise.then` is. If the element is lazily initialized it's worse because we can end up in an unrelated render task as the owner - although that's its own problem. DiffTrain build for commit 8bc81ca.
This lets any element created from the server, to bottom out with a client "owner" which is the creator of the Flight request. This could be a Server Action being invoked or a router. This is similar to how a client element bottoms out in the creator of the root element without an owner. E.g. where the root app element was created. Without this, we inherit the task of whatever is currently executing when we're parsing which can be misleading. Before: <img width="507" alt="Screenshot 2024-05-30 at 12 06 57 PM" src="https://github.com/facebook/react/assets/63648/e234db7e-67f7-404c-958a-5c5500ffdf1f"> After: <img width="555" alt="Screenshot 2024-05-30 at 4 59 04 PM" src="https://github.com/facebook/react/assets/63648/8ba6acb4-2ffd-49d4-bd44-08228ad4200e"> The before/after doesn't show much of a difference here but that's just because our Flight parsing loop is an async, which maybe it shouldn't be because it can be unnecessarily deep, and it creates a hidden line for every loop. That's what the `Promise.then` is. If the element is lazily initialized it's worse because we can end up in an unrelated render task as the owner - although that's its own problem. DiffTrain build for [8bc81ca](8bc81ca)
This lets any element created from the server, to bottom out with a client "owner" which is the creator of the Flight request. This could be a Server Action being invoked or a router.
This is similar to how a client element bottoms out in the creator of the root element without an owner. E.g. where the root app element was created.
Without this, we inherit the task of whatever is currently executing when we're parsing which can be misleading.
Before:
After:
The before/after doesn't show much of a difference here but that's just because our Flight parsing loop is an async, which maybe it shouldn't be because it can be unnecessarily deep, and it creates a hidden line for every loop. That's what the
Promise.thenis. If the element is lazily initialized it's worse because we can end up in an unrelated render task as the owner - although that's its own problem.