-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Parse incoming JSON asynchronously if possible #11207
Conversation
🦋 Changeset detectedLatest commit: 0155c66 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
size-limit report 📦
|
if (response.status >= 300) { | ||
// Network error | ||
throwServerError( | ||
response, | ||
result, | ||
`Response not successful: Received status code ${response.status}` | ||
); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This has already been handled in the parseJsonBody
method so we can remove it here.
c80ba36
to
3f7eecb
Compare
After further testing, it seems that no browser actually moves the parsing off-thread (although the spec would allow for it) and it will be blocking either way, so I will close this. |
Extracted that to #11470 - closing this. |
Since we have support for multipart responses, we had to switch away fromResponse.json
because we had to parse the response manually.At least since it has been added to this repository,
HttpLink
always usedResponse.text()
followed byJSON.parse
. Unfortunately, that moved parsing to the main thread, and it became blocking, which can be problematic with very large responses.This PR tries to move parsing off the main thread where possible. Queries that will have a multipart response are excluded from this - I had managed to make them
async
by creating a newRequest
object, followed by calling.json
on that, but that would (after a short moment) still block the main thread and just make things slower.The tests have been updated to have
Response
present in our test environment, so currently all of our tests are running this new behaviour.We have to make a call with this PR: 89f99f9 adds quite a bit complexity. It's necessary to have the response body available in case of a ParsingError. We could decide to keep
response
off the error object in those cases, and work with the more simple logic I had in place before.Checklist: