-
Notifications
You must be signed in to change notification settings - Fork 49.2k
[Flight Reply] Use prefixed form data backing store for unresolved values #26661
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
Closed
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
1cc3d63
to
525bbf1
Compare
sebmarkbage
added a commit
that referenced
this pull request
Apr 18, 2023
Builds on top of #26661 This lets you pass FormData objects through the Flight Reply serialization. It does that by prefixing each entry with the ID of the reference and then the decoding side creates a new FormData object containing only those fields (without the prefix). Ideally this should be more generic. E.g. you should be able to pass Blobs, Streams and Typed Arrays by reference inside plain objects too. You should also be able to send Blobs and FormData in the regular Flight serialization too so that they can go both directions. They should be symmetrical. We'll get around to adding more of those features in the Flight protocol as we go. --------- Co-authored-by: Sophie Alpert <[email protected]>
Landed as part of #26663 |
kassens
pushed a commit
that referenced
this pull request
Apr 21, 2023
Builds on top of #26661 This lets you pass FormData objects through the Flight Reply serialization. It does that by prefixing each entry with the ID of the reference and then the decoding side creates a new FormData object containing only those fields (without the prefix). Ideally this should be more generic. E.g. you should be able to pass Blobs, Streams and Typed Arrays by reference inside plain objects too. You should also be able to send Blobs and FormData in the regular Flight serialization too so that they can go both directions. They should be symmetrical. We'll get around to adding more of those features in the Flight protocol as we go. --------- Co-authored-by: Sophie Alpert <[email protected]>
EdisonVan
pushed a commit
to EdisonVan/react
that referenced
this pull request
Apr 15, 2024
Builds on top of facebook#26661 This lets you pass FormData objects through the Flight Reply serialization. It does that by prefixing each entry with the ID of the reference and then the decoding side creates a new FormData object containing only those fields (without the prefix). Ideally this should be more generic. E.g. you should be able to pass Blobs, Streams and Typed Arrays by reference inside plain objects too. You should also be able to send Blobs and FormData in the regular Flight serialization too so that they can go both directions. They should be symmetrical. We'll get around to adding more of those features in the Flight protocol as we go. --------- Co-authored-by: Sophie Alpert <[email protected]>
Akshato07
pushed a commit
to Akshato07/-Luffy
that referenced
this pull request
Feb 20, 2025
Builds on top of facebook/react#26661 This lets you pass FormData objects through the Flight Reply serialization. It does that by prefixing each entry with the ID of the reference and then the decoding side creates a new FormData object containing only those fields (without the prefix). Ideally this should be more generic. E.g. you should be able to pass Blobs, Streams and Typed Arrays by reference inside plain objects too. You should also be able to send Blobs and FormData in the regular Flight serialization too so that they can go both directions. They should be symmetrical. We'll get around to adding more of those features in the Flight protocol as we go. --------- Co-authored-by: Sophie Alpert <[email protected]> DiffTrain build for commit facebook/react@d8089f2.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is just a small refactor of the Flight Reply implementation that upcoming features will depend on.
Before this PR, we used to enumerate over FormData object as if it was a stream but it's not really a stream. This is kind of unnecessary since we could just look up entries in it directly. It turns out we're going to need to keep track of seen entries in general and since FormData is a suitable data structure for that, we can just use it as a backing store to save seen entries. Since we already have one in the case of the FormData API we can just use the existing one.
However, we also support streams. In this case we create a new one and then save entries into it as we see them.
Then we only conditionally create Chunk representations lazily as we parse them out of the FormData. At this point we could remove the entry from the FormData to free the memory, since we've "consumed" it. This would mutate the passed value. I stopped short of that for now though.
Additionally, this supports a "prefix" to be added to all our entries in the FormData payload. That way it can co-exist with other user space entries. We'll rely on this internally. This isn't currently exposed as an option but we easily could.