Skip to content
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

Make response parsing helpers public #1372

Merged
merged 1 commit into from
Aug 31, 2020

Conversation

kevinmbeaulieu
Copy link
Contributor

When extending the functionality of Apollo to perform custom logging or other behavior on requests, these functions would be useful to have access to. In particular, making parseResultFast() public enables decode to remain internal while still giving users the ability to parse GraphQL responses. Making parseErrorsOnlyFast() is less significant, however it still would be helpful to centralize the hardcoding of the "errors" key to this one function rather than hardcoding it in both the Apollo codebase and Apollo users' codebases.

@designatednerd
Copy link
Contributor

Definitely making parseResultFast public in the new networking stack - is this something you need ASAP?

@kevinmbeaulieu
Copy link
Contributor Author

Would be nice, but no not urgent if a new networking stack is coming soon

@designatednerd
Copy link
Contributor

Check out #1340 and #1341

@designatednerd
Copy link
Contributor

Actually, I'm going to go ahead and merge this - there's no reason this has to wait on the new stack.

@designatednerd designatednerd merged commit e859be0 into apollographql:main Aug 31, 2020
@designatednerd designatednerd added this to the Next Release milestone Aug 31, 2020
@kevinmbeaulieu kevinmbeaulieu deleted the kb/public-parse branch September 1, 2020 00:11
@kevinmbeaulieu
Copy link
Contributor Author

@designatednerd That new networking stack PR draft is looking good to me btw! One of the main reasons we've needed a custom NetworkTransport has been to do some additional logging of each operation response, but looks like with the new stack we'd be able to just define our own logging interceptor and add it to the chain, using the standard interceptors for everything else

@designatednerd
Copy link
Contributor

Sweet, yeah that's the idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants