You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
How would we represent complex error types using this library. We currently only have a single error message for each error found performing a request. However how can a UI component utilise this effectively. For example say we have a query which requires some kind of authorisation. How can we return this in the UI. More importantly how we give some context of the type of error? i.e in the authorisation problem, the UI should react differently to session timeout errors over not authorised to access a resource. So I think that:
is not enough context or detail to be able to react appropriately as there will be a lot of string parsing. Could we not add an additional field to the errors given with some extra metadata about that error, i.e at least an error code or something more static around a particular error in the system.
Even making the returned error an interface we can implement ourselves would be better. The apollo client GraphQLError returned also seems to have a field called extraInfo even if we could populate that with additional context.
The text was updated successfully, but these errors were encountered:
How would we represent complex error types using this library. We currently only have a single error message for each error found performing a request. However how can a UI component utilise this effectively. For example say we have a query which requires some kind of authorisation. How can we return this in the UI. More importantly how we give some context of the type of error? i.e in the authorisation problem, the UI should react differently to session timeout errors over not authorised to access a resource. So I think that:
is not enough context or detail to be able to react appropriately as there will be a lot of string parsing. Could we not add an additional field to the errors given with some extra metadata about that error, i.e at least an error code or something more static around a particular error in the system.
Even making the returned error an interface we can implement ourselves would be better. The apollo client
GraphQLError
returned also seems to have a field calledextraInfo
even if we could populate that with additional context.The text was updated successfully, but these errors were encountered: