Handle GraphQL query error states using Apollo
Similar to loading states, Apollo also gives us a simple error object from its useQuery hook. We can use this to handle what to display to the user if there's an error. There's a catch, however: your server might still send you partial data when there's an error, and Apollo blanks this data out by default, so that you don't forget to handle that state. We'll see how to handle this use-case by specifying an errorPolicy.
Instructor: [0:01] Something broke on our backend. Whenever we click on the Shopping category, the backend throws an error. If we look at the request, we see some problems here, with details of what went wrong exactly. The user doesn't see this. As far as they're concerned, they're just staring at the blank screen right now, with no idea of what to do next.
[0:22] Luckily, Apollo gives us an error flag that we can use to return a custom template when there are errors. If we click on the second category again, OK, cool, at least we get an error message. Let's have a closer look at that request again. It did give us an error but it also gave us some data back, with one of the objects being NULL.
[0:48] Now we can decide how to handle the situation. Do we always want to display this message when there is an error, or if there is data, do we still try to display what's left of it?
[0:59] Let's try to still display the data. I'll change my error handler to only display the message if there is an error and no data at all. My hope is that in my case, it's going to jump over this and still display the notes. I'm also going to log both the data and the error object.
[1:20] If I click on Shopping, I see the error here, but the data is undefined. How come? It was there on the network request. Turns out, Apollo Client, by default, is overly cautious and tries to guard you from forgetting to handle errors correctly. If there is an error, it blanks out the data as well, to make sure that you see that and you remember to handle the problem.
[1:45] To stop it from doing it, similar to our fetch policy, I'll declare an error policy on my query, and set it to all. This is going to tell it that if there is an error, to leave the data alone, because I might want to display it.
[2:00] Now that we might get NULL notes in here, I need to filter them out. Now if I click on Shopping, I get both my data and the error message back. We can see all the notes appearing, except one of them.
[2:16] If I refresh the page, and go to the Network tab and take the network offline, and now I go back to my Shopping page, I see the full error message. That's because there's no network, so there's no data, so I get the message.
[2:31] Let's pause for a bit and look at what we just built. In just a few lines of code, we are handling errors, we're doing snappy offline responses for data we already downloaded, and if I slow down the network and enable it, we're also handling loading states. Just by using Apollo Client, we're getting guided towards a good user experience.
Member comments are a way for members to communicate, interact, and ask questions about a lesson.
The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io
Be on-Topic
Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.
Avoid meta-discussion
Code Problems?
Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context
Details and Context
Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!