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

feat: pass context to formatErrors #2140

Closed

Conversation

JonathanCallewaert
Copy link

@JonathanCallewaert JonathanCallewaert commented Dec 27, 2018

If you want to show different types of errors based on your context, for instance personalized errors based on the user (language) that has sent the request, ...

TODO:

  • Update CHANGELOG.md with your change (include reference to issue & this PR)
  • Make sure all of the significant new logic is covered by tests
  • Rebase your changes on master so that they can be merged easily
  • Make sure all tests and linter rules pass

@apollo-cla
Copy link

@JonathanCA97: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/

@JonathanCallewaert JonathanCallewaert changed the title pass context to formatError feat: pass context to formatErrors Dec 27, 2018
@JonathanCallewaert
Copy link
Author

@abernix , when is this PR going to be watched?

@tim-soft
Copy link

any blockers here? I'm very keen to see this merged @martijnwalraven @abernix

@JonathanCallewaert
Copy link
Author

@martijnwalraven any blocking issues? I want to know why this isn't reviewed/accepted yet.

@abernix abernix self-assigned this Feb 13, 2019
@fromthemills
Copy link
Contributor

It would be very useful to have the context available in the format function.
Is there any way we can get this moving again? @abernix @JonathanCA97
An extra argument in a function seems like a reasonable (not breaking) change. Any blokkers I can help with?

@abernix
Copy link
Member

abernix commented Jun 30, 2019

I see the value you might gain by having this additional context argument, however, the formatError method is meant to match the function signature of the underlying graphql-js library, as defined here and for compatibility reasons, I think it should stay true to that signature.

That doesn't mean that there shouldn't be a way to accomplish what you're (likely) trying to do though and I'd encourage you to explore the new didEncounterErrors life-cycle hook which was introduced in #2719. There's a bit of an example of how to use it in #1709 (comment) which should allow you to react to the presence of errors with context-awareness. (There will be documentation added to #2008 for didEncounterErrors, but I hope that example does the trick for now.)

I think we should explore the possibilities of that new life-cycle hook. Keep in mind that it's possible to attach properties to an error object in didEncounterErrors and that property will eventually be present on the error received by formatError.

If this still doesn't work out, please open a new issue so we can come to a consensus on the best approach before moving into a PR. Ultimately, we'd like to have this be addressable within the request pipeline API.

@abernix abernix closed this Jun 30, 2019
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants