Essential Logging Techniques with @microsoft/sp-core-library

Introduction

Ever you wonder what the Log class of the @microsoft/sp-core-library does?

I did, so I tried it a little bit more in order to better understand how it works and what can be done with it.

If you need a reference about how to use it you can have a look at a simple sample project here.

First thing first: the developer dashboard

In order to take advantage of the Log class the first thing to keep in mind is the developer dashboard.

If you don’t know what it is you can have a look at my previous article here, otherwise just skip to the next section.

How it displays

The sample solution I’ve built simply shows a text, but the interesting part is in the developer dashboard and, more precisely, in the Trace tab.

Here is a screenshot of the dashboard:

Here you can see the different tracing level with also different colors:

• verbose
• info
• warning
• error

Also, pay attention to the Source and Message columns, we’ll cover those soon in the next section.

When using the Trace tab it’s useful to filter the Level , Scope and Source columns in order to remove the “noise” from other loggings and focus only on the important ones.

Show me the code

The Log class is imported from the @microsoft/sp-core-library, to achieve that you need to specify the import where you need to use the logging:

import { Log } from '@microsoft/sp-core-library';

After the import, you can proceed using the logging you need.

All the logging functions have two required parameters:

• source: this parameter allows to specify a sort of grouping, for example you can use the class name or a solution wide string to group the loggings of your solution. Pay attention to the source’s length, if it’s more than 30 characters it will be truncated.
• message: this parameter allows to specify a string that will be logged. Pay attention that the maximum length of this field is 150 characters, the exceeding characters will be truncated. The message parameter has a different name for the error function but the functionality is the same.

Verbose

This method is used to add, as the name suggests, more logging to the console, which can be very helpful when debugging or trying to understand how the code is executing step by step. By introducing additional log statements, you gain more visibility into the program’s flow, the values of variables at certain points, and any unexpected behavior that may occur. In the sample solution, I’ve used the following code to demonstrate how these extra logs can provide useful insights during runtime:

Log.verbose('LoggingSample', 'This is a verbose message', this.context.serviceScope);

Here, just for reference, I’ve set also the service scope but it’s not a required property.

Info

This method is used to log informational messages, which are typically non-critical outputs intended to provide insight into the normal operation of an application. Informational logs can be especially useful for tracking the flow of execution, confirming that certain processes have been triggered, or simply documenting the system’s behavior at different points in time. Unlike warnings or error messages, these logs do not necessarily indicate a problem; instead, they serve as a way for developers and system administrators to better understand what the program is doing behind the scenes.

In the sample solution I’ve used the following code:

Log.info('LoggingSample', 'WebPart Initialized!');

This will render as follows in the developer dashboard:

Warning

This method is used to log warning messages, which indicate that something unexpected has happened or that there may be a potential issue in the system, but not necessarily one that stops the application from running. Warnings act as signals to developers or administrators that attention may be needed, even if the program continues to function as intended. For instance, a warning might be logged when a configuration file is missing a non-essential value, when an API request takes longer than expected, or when a deprecated function is being used.

These messages are valuable for proactively identifying and addressing issues before they escalate into errors or critical failures.

In the sample solution I’ve used the following code:

Log.warn('LoggingSample', 'This is a warning message');

This will render the following in the developer dashboard:

Error

This method is used to log error messages with the error to be traced, providing critical information when something goes wrong during program execution. Error logs usually capture details such as the error type or a description of what happened. This makes them an essential tool for debugging and troubleshooting, as developers can quickly identify the root cause of the error.

Unlike warnings or informational logs, error messages usually indicate that a specific operation could not be completed as expected, which may affect the functionality of the application.

In the sample solution I’ve used the following code:

Log.error('LoggingSample', new Error('This is an error message'));

This will render the following:

Conclusions

The logging offered out-of-the-box from the SharePoint Framework is pretty useful and already included in all the modern pages of SharePoint Online. I think that, if you don’t need to log complex objects or lengthy strings, this is the right tool for you.

If you want to dig a bit more you can find the official documentation here.

Hope this helps!