adding an onError prop ? about urql

[morajabi]

That one which is directly on the client makes more sense to me as for reporting to Sentry.

Although most of the GraphQL errors are to be handled by the app in the UI. You should catch the others (errors or bugs) in the server side (e.g. Apollo Server) and only pass the errors which are for the users to the client.

The way I might be handling this is to use ConnectHOC and check for error in the componentWillRecieveProps which is not the best practice, especially now that it is deprecated I should use the new hook.

[shrynx]

@morajabi i want to handle error in component but also want to have associated side effects for the corresponding error. For eg, if the page listing todo's has error, then push pack to home page or maybe 500 page.
And yes, errors like these should be handled on server-side (in an ideal world), but there are times, when server side has uncaught bugs and i want to gracefully handle them on ui.

Currently i am using getDerivedStateFromProps (componentWillRecieveProps has been / is getting depreciated) to check in the child component of Query if there was error or not, but for this i have to always use a class component as a child of query.
The other approach is to throw an error and catching it in componentDidCatch, enabling me to use stateless components to render result of Query.

[morajabi]

I'm not pointing at Redux, as I didn't mention and don't use Redux. Urql exports a ConnectHOC which is a HoC.

I said handling uncought errors with Sentry is supposed to be done on the server side. So you just need to show an error screen in the UI. So you can gracefully handle them in UI, I think you're not quite used to the render props pattern yet, maybe.

<Connect> 
{({ error }) => {
  if (error) {
    return <ErrorScreen error={error} />
  }
  // ...
}}
</Connect>

This is quite like how React apps should be architectured.

Throwing an error makes total sense as well, and I think it is there for situations like this, but most of the time it is not necessary.

[shrynx]

@morajabi ahh sorry i miss read about Connect 😅 . my problem is I don't want to display error, i want to change route (for eg).
Also backend team doesn't use sentry and i do want to use it for failing queries.

PS: Don't mind but, I don't feel there is a single way of how react apps should be architectured, in my app i would like to re route user on error and see nothing wrong in that

[shrynx]

i am sticking to throwing errors and catching the , thus closing the issue