How to configure a solid frontend ReactJS stack — Error detection and reporting (4)

Adam Giacomelli
Sep 5, 2018 · 3 min read

The series consists of the following parts:

In this part we’ll focus on error detection and error reporting of your ReactJS application. The main reason to have this featured in your application is that while it is a good idea to get the errors out of the application before deploying to production there will always be edge cases and unforseen situations where the application will crash. Using a tool that reports the crashes that happen to users in production can go a long way towards developing a truly robust app.

There are a few interesting options for error detection in a production application — my choice would be:

Sentry

Sentry has proven to be extremely useful in any application where I’ve used it before. It has a really simple premise — any error in the application is reported to the service and it is also easy to let the users know an error has occured that it has already been reported and enable them to add a report.

Easy to implement and extremely useful.

Notable mention: A similar solution is provided by bugsnag but Sentry feels like a more mature solution.

General pointers

Even with a good monitoring/reporting service running on your site most of the effort towards a solid application can be done while coding.

There are a few things that I try to do while developing ReactJS applications that help.

Error boundaries

ReactJS v16+ implements a concept of error boundaries — simply said these catch any exceptions that occur in the components it wraps. This is very useful since you can wrap various parts of the application in error boundaries and easily separate different scopes of the project and manage the errors thrown in a certain scope any way that makes sense.

Exception handling

JavaScript supports exceptions — this means that all error reporting can and should be passed by throwing an exception. There are many ways in which to handle that but there are a couple of things you should not do:

  • Catch an exception, ignore the data from the exception and throw another one. You should atleast include the original exception data as a part of your exception.
  • Catch an exception and do nothing to keep the app working. If it seems to be broken you should fix it.

Otherwise the rule of thumb is that you should keep track of any errors your app is reporting and handle them appropriately — it is entirely possible to stumble upon a specific case where it makes sense to run backup logic in case of specific errors in the error catcher.

There is another interesting option on how to handle exceptions — there is the possiblity of a global error event handler — window.onerror. Any function that is set here can catch any errors that are thrown and decide which to handle and which to report by returning true or false. It’s a catchall method and it should be used with caution. The onerror function can be set as a prop for any html element (see element.onerror) to only catch the errors thrown inside the element.

I will not go into details about the usability of this feature — it is generally bad form to hide any errors but this can prove useful when debugging legacy/bad code and figuring out why no errors are reported.

Wrap up

This is the fourth article in the series. In the next part we will focus on server side rendering.

Adam Giacomelli

Written by

I am an engineer, software architect and the JavaScript tech lead @povioLabs.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade