-
Notifications
You must be signed in to change notification settings - Fork 7
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
"GraphQL error" text string in error messages #46
Comments
Can anyone give an update on this task please? |
+1. This error message is quite annoying. |
What's the consensus on the best way forward here? Based on thumbs up in apollographql/apollo-client#1812, it looks like people want to remove the code that prepends |
IMO, the best solution will be to implement the ability to format/change error(s) inside apollo-link-error and/or onError middleware. It should be possible to change error message right before passing it to a final handler (onError callback of Query/Mutation) and no other formatting should be applied after changes made by my own code (currently, even if I change error, the annoying “GraphQL Error” prefix will be automatically added before passing error to the query/mutation callback) |
I would really enjoy being able to do something like:
The actual way to do this makes the code really ugly, I need to replace it in 19 different files. Why not moving the addition of the "GraphQL error:" on the onError function instead of in the ApolloLink? |
Any update here? |
This error message is quite annoying. Any update here? |
This error message is quite annoying. Any update here? x2 |
This error message is quite annoying. Any update here? x3 |
+1 |
Here I am stumbling once more upon the issue I originally created two years ago… In a way it's a bit like randomly meeting an old friend in the street! Also this might help others, but here's a workaround to access the full error object instead of the "composite" one produced by Apollo Client: apollographql/apollo-link#1022 (comment) |
Just created an enhanced function for this. But if we can do this on the link level it would be better. const ANNOYING_GRAPHQL_ERROR_HEADER = 'GraphQL error: ';
const removeAnnoyingHeader = error =>
error && {
...error,
message: error.message.replace(ANNOYING_GRAPHQL_ERROR_HEADER, '')
};
const useQueryEnhanced = (...options) => {
const data = useQuery(...options);
data.error = removeAnnoyingHeader(data.error);
return data;
};
const useMutationEnhanced = (...options) => {
const [mutation, { error, ...remaining }, ...remainingResult] = useMutation(
...options
);
const errorEnhanced = removeAnnoyingHeader(error);
return [mutation, { ...remaining, error: errorEnhanced }, ...remainingResult];
};
export const AuthProvider = props => {
const [authenticated, setAuthenticated] = useState(initialAuthData);
const { client, data: { auth } = {}, refetch } = useQueryEnhanced(AuthQuery);
const [loginMutation, { loading, error }] = useMutationEnhanced(
LoginMutation
);
} |
Any update? This seems to be a very logical suggestion, I can't believe after a more than a year this has barely any sign of being considered. |
Also looking for this, 👍 |
This seems to be a very logical suggestion +1 |
Also waiting for a solution. |
+1 Would be nice to have a configurable option for this. |
+1 to everyone |
+1 |
1 similar comment
+1 |
With the original issue being from 2017 I was very optimistic that this would have been resolved. It seems quite trivial to allow users to opt out of the prepended error text. The situation I find myself in is that I want to show the user the error message thrown from a failed mutation created from the useMutation hook. I am using There is no need to have this prepended text for the end user. There should be a way to opt out of this especially for user facing errors. I still think |
👍 |
Any updated on this?
|
Guys. This issue, along with apollographql/react-apollo#3507 have both been open for some time. This makes me very sad. When will they be merged? Thanks! |
If you can not handle simple, consensus maintenance for a tiny feature do not advertise Apollo as production ready. |
Assuming that we can send multiple Graphql queries per request, errors could happens in more than one place.. so the correct way to deal with errors (show to users, for example) is using the property
|
I had to write this helper to resolve it. It would be great if this could be fixed.
|
Initially thought there was a config to turn this off. As it is, I will be extracting the message using @austinChappell solution |
Implemented in apollographql/apollo-client#3892 and merged. This will be in Apollo Client 3.0. Thanks all! |
Migrated from: apollographql/apollo-client#1812
The text was updated successfully, but these errors were encountered: