[pull] main from facebook:main #186
Merged
Conversation
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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
…33947) If you pass a promise to a client component to be rendered `<Client promise={promise} />` then there's an internal await inside Flight. There might also be user space awaits but those awaits may already have happened before we render this component. Conceptually they were part of the parent component and not this component. It's tricky to attribute which await should be used for the stack in this case. If we can't find an await we can use the JSX callsite as the stack frame. However, we don't want to do this for simple cases like if you return a non-native Promise from a Server Component. Since that would now use the stack of the thing that rendered the Server Component which is worse than the stack of the I/O. To fix this, I update the `debugOwner`/`debugTask`/`debugStack` when we start rendering inside the Server Component. Conceptually these represent the "parent" component and is used for errors referring to the parent like when we serialize client component props the parent is the JSX of the client component. However, when we're directly inside the Server Component we don't have a callsite of the parent really. Conceptually it would be the return call of the Server Component. This might negatively affect other types of errors but I think this is ok since this feature mainly exists for the case when you enter the child JSX.
…33948) We need a "value" to represent the I/O that was loaded. We don't normally actually use the Promise at the callsite that started the I/O because that's usually deep inside internals. Instead we override the value of the I/O entry with the Promise that was first awaited in user space. This means that you could potentially have different values depending on if multiple things await the same I/O. We just take one of them. (Maybe we should actually just write the first user space awaited Promise as the I/O entry? This might instead have other implications like less deduping.) When you pass a Promise forward, we may skip the awaits that happened in earlier components because they're not part of the currently rendering component. That's mainly for the stack and time stamps though. The value is still probably conceptually the best value because it represents the I/O value as far user space is concerned. This writes the I/O early with the first await we find in user space even if we're not going to use that particular await for the stack.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.3)
Can you help keep this open source service alive? 💖 Please sponsor : )