When to use error boundaries

ErrorBoundary is a great pattern for sure. It takes the try-catch concept into declarative JSX. The first time I saw it, I immediately came up with the idea to wrap the whole application into a boundary. This is fine, but it is not the only use case.

Consider the following use cases for error boundaries:

• Widgets: Given some incorrect data, your widget may run into problems. If, in the worst case scenario, it cannot handle the data, it may throw an error. You will want the rest of the app to be usable, given that this widget is not crucial for the rest of the application. Your analytics code should collect the error and save at least a stack trace so that the developers can fix it.
• Modals: Preserve the rest of the application from the faulty modal. These are usually meant to display some data and short messages. You do not want a modal to blow up your application. Such errors should be considered very rare, but better safe than sorry.

• Boundaries on feature containers: Let's say that your app is divided into major features that are represented by container components. For example, let's take a messaging app such as Facebook Messenger. You may add error boundaries to the sidebar, my story bar, footer, start new message button, and messages history list view. This will ensure that, if one feature breaks, the others have a chance to still work properly.

Now we know about all of the pros, let's discuss the cons ones: Mixins.