Introduction

Any application written in a modern day programming language will be prone to software errors. When an application is written in JavaScript, there is a chance of unexpected behaviour through human error. A developer is not perfect. He will at times make mistakes that can lead to bugs. When a system has an error, you need some way of recording what happened. To achieve this takes purposeful work towards logging and reporting bugs that arise within your application.

When code executes on a client-side browser, it is difficult to collate and report errors on their machine. If you have code that is client-side, then how do we collect remote client information onto an internal system? How do we organise such information? And how do we yield significant results without being overwhelmed by false-positives?

Within this article, I will provide you with the best practices to achieve an error reporting system that helps you figure these questions out. I will provide the best practices that can help you with your JavaScript error reporting.

Log Errors to The Server

I may have hinted in my introduction that the key to JavaScript error reporting is to be able to retrieve that data from a client’s browser, and store it within an internal server of our own. Tools that can help you retrieve this information are software such as Sentry, Bugsnag, and TrackJS. This article will not go into how to use these tools, but they are the bread and butter in being able to deal with client-side errors, without rolling your own solution.

The most important thing when it comes to JavaScript error reporting is to be able to log all your errors into a central server that you control. This will allow you to take further action on such data, enabling you to report and learn from it.

Signal Vs. Noise

When using error reporting tools, it is important to calibrate them correctly. You must consider the level at which you want to log, either debug, informational, or error levels. If you decide to log at debug level, then this will give you the most amount of information that can be understood about a JavaScript application. It sounds like a great idea to have more information because wouldn’t that mean you can make a more informed decision on what are problem areas? and what your focus should be for the next feature iteration?

The problem with fine-tuning your logging to debug level, is that you can suffer from information overload. It becomes harder to see the wood through the trees, that is, you have no idea what the true problems your clients are facing from a day-to-day basis when working with your application. If you reduce the amount of noise received from client browsers, then it will allow you to diagnose real errors swiftly.

Use Contextual Data

When logging errors from a client’s browser, or from JavaScript running server-side, you need to understand the context in which an error occurs. What was the current CPU usage? Was the box running out of memory? Was there a high network latency?

These are the basic questions you should ask yourself when an initial diagnosis is performed. If an error is reported without a stack trace or environmental data, then it becomes harder to understand how to reproduce the error and fix it. There can also be specific metrics like what does the current memory heap look like? What are the current values of the variables in the current context in code?

All these questions matter when trying to understand how to fix bugs, and not fix the wrong problem.

Source Maps For Error Tracking

JavaScript looks completely different when working locally in a development environment, and when the code runs in production. If JavaScript is deployed into a production scenario, then minifying and bundling are steps followed to improve application performance by reducing the JavaScript code footprint. Unfortunately, these processes uglify the JavaScript, which means that the code is no longer human-readable.

If you want to collect data around resources available or save the current code version that was ran on the deployed environment, then you will have to make this code human-readable. This is where source maps are useful. A source map can convert the uglified JavaScript into human-readable JavaScript; a very important step when understanding the context of an error.

Conclusion

Client-side browsers are somewhat of a black box. It can be hard to understand how a user interacts with your application, and how you can improve your application to make it easier for them. The introduction of JavaScript error reporting into your application can work wonders in narrowing this knowledge gap. Why rely on users manually reporting bugs, when you can automate the process?