You can set the error component that will show when a component has an error during async loading. You can force the error to show manually as well.
Instructor: [00:00] I'm going to try to load a file that doesn't exist. We have two buttons, one that loads the Home file, which does exist. The other button tries to load broken.js, which is not going to exist.
[00:12] When I click the broken button, it's going to set the state to broken. It's going to pass that to the tab prop. When the tab prop comes in and sends it to the import function, it's going to look for broken.js, and it's going to get an error.
[00:30] By default, universal will show this error message. It's pretty helpful, especially since it specifies which module that it couldn't find. You can change the error component that is shown by specifying the error option. I've created this simple notFound component. I'm going to pass it to the error option. Now, when I refresh and click broken, here's a simple component that I made.
[01:00] There are two other props that the output component from calling universal can receive. One of them is the error prop. What it does is it takes a Boolean, either true of false. You can basically force the error to be on.
[01:20] This is in case you are having maybe another error that you know of, and you want to tell universal, "Hey, I know there's an error, so just show the error component that you're configured to show." If we save that and refresh, even if I click Home, which is a good file, we're still going to see this error show up.
[01:42] The other prop is onError. This is more of a listener. I'm going to console log out the error that I receive as the parameter to this function. When I click broken, I'm actually going to see the same error message that is shown with the default component. I see "Error cannot find module 'broken.'" Then I also get a bit of a stack trace.
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!