If you already have a subscription, you can sign in.
Enjoy free content straight from your inbox 💌
00:00
We've already explained how suspense lets you seamlessly show a fallback UI while data is loading and swaps it with the final user interface once all pending tasks have successfully completed. But a critical thing you also need to consider is what happens if the loading fails or errors out to demonstrate. We have a simple page that displays a square root component, and this is a component that we've looked at before. It collects a value from the user in a simple input, and then based on that value makes a fetch call to an API to fetch the square root. We pass that promise to the square root result component,
00:32
and while that promise is still pending, we show a fallback UI powered by a suspense boundary. The square root result component simply awaits that promise with use, which automatically integrates with the suspense boundary created by the parent. So within the application, as you modify the input, a new promise is created with the fetch for the result. And while that promise is pending, we see the suspense boundary calculating message. But what happens if that promise is rejected and we end up in an error situation? In this example, if we try to calculate the square root
01:04
of a negative number, which would actually result in an imaginary number, that is not something that this API can handle, and therefore the promise is rejected. We are not handling this case right now, which is why the application crashes and we end up with this error screen. Just like a suspense component is used to show a fallback UI for pending states, the error boundary component is used to show a fallback UI for error states. We've looked at error boundaries in our course on React, so let's create a simple error boundary specific to the square root component. We start off by marking this file with you client.
01:37
Because we plan to handle browser click events, we are using an NPM package called React Error boundary, so we don't have to create the core error boundary component ourselves for our fallback ui. The React error boundary package will provide us with the error along with the reset function. We simply display the error message to the user and then provide a simple button that when clicked will invoke the error boundary reset function. With this fallback UI in place, we create an error boundary component specific to the square root component. It'll accept the children, which will be displayed when there is no error, along with the reset function
02:10
that the user will be able to invoke to take them back to a known good state. Within our squa root component, we simply display the error boundary with the fallback wide to our custom fallback on reset wide to the past and reset function and the children contained within the error boundary. With this custom error boundary component created, we jump back to our square root component and then simply wrap the entire component with our custom error boundary. Note that it is nice to handle the errors and the pending states separately. As an example, in our particular error state, we don't want the user to mess around
02:41
with the input anymore, which is why our error boundary wraps the entire component, and suspense only wraps the result portion With our error now handled successfully, let's demonstrate this within the browser. If the user provides valid input, we see the pending state along with the final calculated result. However, if They provide an invalid value, an error occurs and we handle that gracefully within our error boundary, which displays the message to the user along with the option to reset the user interface to a known good state. Note that an error boundary should only be used for exceptional circumstances.
03:13
As an example. In this particular case, we could probably handle the negative numbers before making that API call. Just like suspense can handle pending states for any number of direct and indirect children, the error boundary will also action all unended errors for any of its sub-components. To demonstrate, we have a page that is going to display two square root calculators. These square root calculators are not handling their errors anymore. These are the original versions that do not contain an internal error boundary. So if you run this application within the browser, we see two square root calculators
03:46
and both will function fine as long as the provided value is valid. However, if either of them is passed in a negative value, the application will crash due to an unhandled promise rejection. We can create an error boundary for the entire page. We use the same fallback UI that we had before, which displays the error message along with the reset button and then specific to the page. We use the error boundary via to that fallback and with the reset function wire to simply reload the current page. This is a very general purpose error boundary as it simply displays the error message and provides the user with the button
04:18
that simply reloads the current page. We wrap both our square root calculators with this error boundary, and now when we jump into the application, as long as these components are behaving fine, we see the final result. But if an error occurs in either of these components or any of the children, you see this fallback user interface from here, the user can click the reset button to reload the page and start from fresh.