Configurable logging in Angular projects

When developing code in Angular, it’s a common practice to log diagnostic information to the console. This is helpful when you are developing, but you need a way to prevent having verbose logging data from being emitted when you deploy your application to production.

In this article I will explain how to create a custom logger that makes it easy to deploy to separate environments with configurable logging levels.

When writing Angular code, I invariably add logging code to display the state of the system to help me understand what’s happening at run time. Typically this will simply be code that logs messages out to the console.

The following image shows an example of logging statements written to the console.

All of my logging statements start with the name of the class and use different logging levels such as Info, Warnings, and Errors to make it easier to filter messages using the development tools. Having messages formatted this way helps with diagnosing issues when they arise.

The following image shows messages filtered to display only Info level messages from my AuthGuard guard.

Over time, the amount of information being written to the console becomes vast but has enough development value that we need to find a way to manage it.

Throughout the course of this article, we will develop a logging service that is configured via an external configuration source. Logging statements will then be routed via the logging service as shown in the following example.

The first step in providing a configurable logger is to create an external configuration source which will simplify the task of customizing environmental specific configurations. Start by modelling a simple service to maintain a logging level property.

Configuration data will be held in an external configuration file named config.json which contains the following content by default.

This file can be transformed in build and release pipelines to change the logging level based on environmental specific variables.

That’s it for our Configuration Service. The next task is to create a Logging Service and inject it with our Config Service so that we can conditionally emit logging data based on the configured value of the logging level.

Create a new service and read the logging level from our configuration like so.

At the heart of the logging service is a log method which accepts logging messages and writes them to the console using a method based on a desired logging level and taking into account our configured level.

It’s a pretty straightforward method. At the beginning it calls a private method named shouldLog that determines whether the current message should be logged based on our configured level.

The following code shows the logic behind the shouldLog method.

Finally, a few helper methods to make it easier for consumers of the Logging Service to use it.

In this article we’ve taken a look at how to externalize configuration data and use environment-specific configuration to conditionally display logging messages.

I would encourage you to read my article on deploying to Firebase from Azure DevOps to see an example of how to transform the configuration file from a release pipeline.

Hopefully you have found this article interesting and good luck with your future logging adventures in Angular!

Related posts:

Advertising Week Asia 2018 kicked off Monday with a full agenda. This year Dentsu Isobar President and CEO Hidetoshi Tokumaru and Chief Business Transformation officer Emmanuel Flores presented The…