Giter VIP home page Giter VIP logo

Comments (31)

fgiarritiello avatar fgiarritiello commented on May 14, 2024 29

Can anyone give an update on this task please?

from apollo-feature-requests.

garfiaslopez avatar garfiaslopez commented on May 14, 2024 15

This error message is quite annoying. Any update here? x2

from apollo-feature-requests.

hwillson avatar hwillson commented on May 14, 2024 15

Implemented in apollographql/apollo-client#3892 and merged. This will be in Apollo Client 3.0. Thanks all!

from apollo-feature-requests.

KaneLabs avatar KaneLabs commented on May 14, 2024 9

If you can not handle simple, consensus maintenance for a tiny feature do not advertise Apollo as production ready.

from apollo-feature-requests.

pfarnach avatar pfarnach commented on May 14, 2024 8

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 "GraphQL error: . Should we also remove the Network error: prepended string for consistency? It seems like if a dev is really interested in distinguishing the two, one option is to configure the onError middleware like in this example. I'm happy to make a PR for this, just say the word.

from apollo-feature-requests.

williangd avatar williangd commented on May 14, 2024 8

This error message is quite annoying. Any update here?

from apollo-feature-requests.

dunika avatar dunika commented on May 14, 2024 8

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 final-form which relies on the onSubmit throwing an object of a particular shape so that it can be added to the form state.

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 apollo-link-error should get the full, unedited prepended errors in all their glory for logging and dev purposes. But maybe there is a way for apollo-link-error to edit the final user facing error message?

from apollo-feature-requests.

SachaG avatar SachaG commented on May 14, 2024 6

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)

from apollo-feature-requests.

ralphchristianeclipse avatar ralphchristianeclipse commented on May 14, 2024 6

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
  );
}

from apollo-feature-requests.

jakec-dev avatar jakec-dev commented on May 14, 2024 5

+1. This error message is quite annoying.

from apollo-feature-requests.

lizzieshipwreck avatar lizzieshipwreck commented on May 14, 2024 4

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!

from apollo-feature-requests.

mattsrobot avatar mattsrobot commented on May 14, 2024 3

This error message is quite annoying. Any update here? x3

from apollo-feature-requests.

ralexandr avatar ralexandr commented on May 14, 2024 2

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)

from apollo-feature-requests.

zachweinberg avatar zachweinberg commented on May 14, 2024 2

+1

from apollo-feature-requests.

erangakm avatar erangakm commented on May 14, 2024 2

+1 Would be nice to have a configurable option for this.

from apollo-feature-requests.

sebmor avatar sebmor commented on May 14, 2024 1

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.

from apollo-feature-requests.

zjd2035 avatar zjd2035 commented on May 14, 2024 1

Also looking for this, 👍

from apollo-feature-requests.

rushairer avatar rushairer commented on May 14, 2024 1

This seems to be a very logical suggestion +1

from apollo-feature-requests.

ljukas avatar ljukas commented on May 14, 2024 1

Since people are still posting here looking for solution, look at what @SachaG posted above: Solution

from apollo-feature-requests.

webdevike avatar webdevike commented on May 14, 2024 1

Any updated on this?
this is what I ended up doing but it's still not ideal

catch ({ graphQLErrors }) {
console.log('handle errors', graphQLErrors)}
}

from apollo-feature-requests.

OtacilioN avatar OtacilioN commented on May 14, 2024

I would really enjoy being able to do something like:

const errorLink = onError(({ networkError, graphQLErrors }) => {
  if (graphQLErrors) {
    graphQLErrors.forEach(({ message, locations, path }, index) => {
      console.log(
        `Message: ${message}, Location: ${locations}, Path: ${path}`,
      );
      graphQLErrors[index].message = message.replace('GraphQL error:', '');
    });
  }
  if (networkError) console.log(`[Network error]: ${networkError}`);
});

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?

from apollo-feature-requests.

OtacilioN avatar OtacilioN commented on May 14, 2024

@marlonchalegre

from apollo-feature-requests.

brunocascio avatar brunocascio commented on May 14, 2024

Any update here?

from apollo-feature-requests.

slinden2 avatar slinden2 commented on May 14, 2024

Also waiting for a solution.

from apollo-feature-requests.

MiKaminskas avatar MiKaminskas commented on May 14, 2024

+1 to everyone

from apollo-feature-requests.

catherineleung avatar catherineleung commented on May 14, 2024

+1

from apollo-feature-requests.

monbo avatar monbo commented on May 14, 2024

+1

from apollo-feature-requests.

sreevisakh avatar sreevisakh commented on May 14, 2024

👍

from apollo-feature-requests.

tiagowippel avatar tiagowippel commented on May 14, 2024

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 graphQLErrors on the err object (wich is an array btw, and do not have the "GraphQL error:" string). This is my understanding...

.catch(err => {
    if (err.networkError) {
        appStore.showError('Erro na requisição.');
    } else {
        err.graphQLErrors.forEach(err => {
            appStore.showError(err.message);
        });
    }
})

from apollo-feature-requests.

austinChappell avatar austinChappell commented on May 14, 2024

I had to write this helper to resolve it. It would be great if this could be fixed.

export const extractGQLErrorMessage = (error: ApolloError) => {
  const { 1: errorMessage } = error.message.split('GraphQL error: ');

  return errorMessage;
};

from apollo-feature-requests.

arvinsim avatar arvinsim commented on May 14, 2024

Initially thought there was a config to turn this off. As it is, I will be extracting the message using @austinChappell solution

from apollo-feature-requests.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.