Whether you are an adventurous admin or a Salesforce sage, you will have come across Lightning Components at one time or another. These wondrous little things are the powerhouse behind modern Salesforce and can be anything from an individual field on a page layout, to the navigation bar we use to whizz around our favourite orgs all day.
While most of the time everything works hunky-dory, occasionally a component can go rogue and throw a scary error message! However, don’t fret, debug mode is a wonderful tool hidden away in the setup area that can turn off all those pesky bugs – but on a more serious note – it can be a real asset in finding the cause and eventually squashing those elusive issues.
What does Debug Mode do?
Debug mode at its simplest assists developers in solving bugs (they may have caused!) within Lightning Components more easily, by changing the way Salesforce presents that code to your browser.
Debug mode fundamentally changes the way Lightning Components are loaded when it’s active, and varies depending on whether you are working with Aura or Lightning Web Components (LWC).
Debug mode adds some colour changing counters to the top right corner of the screen and removes minification of Salesforce and custom component code.
Image: note the colourful counters to the right!
These two subtle changes have big impacts on the org you’re working in and the data presented to you when an error occurs. So, let’s take a closer look at what’s really going on!
EPT: “The Fancy Counters”
These counters can easily be identified in the top right corner of the page, prefixed with the label ‘EPT’, meaning ‘Experienced Page Time’. There should be two counters (hopefully in green!) next to each other with different units.
Image: close up of the counters, notice their units, and different colours from figure 1.
The first counter is how long the page took to load in seconds. The longer the load time, the higher the number and the colour will begin to change from green to orange and eventually red if the page loads at a snail pace.
This metric is usually collected and exposed in the Lightning Usage App and when debug mode is on, will likely show a much slower number than normal due to the implications of having debug mode enabled. In practice, you only want to use this gauge as a relative performance indicator, and not an absolute one. If you need accurate values in a production ready state, you can enable this counter without the rest of debug mode by adding “?eptVisible=1” to your page URL. For example – “https://my-domain .lightning.force.com/one/one.app?eptVisible=1”
The second counter is measuring the amount of data stored by various actions undertaken by the page. The higher the number, the more memory is being used.
Depending on your use case, a higher number might be a good thing, indicating that more data is being cached and generally improves the snappiness of your components. On the other hand, an excessively high, or one that is rising faster than a spring tide, could indicate memory leaks or other issues within your component! It is best to investigate those further, before they gobble up your computer’s ram faster than you do your mothers cooking!
Code mini-if-whatcha-ma-call-it?
The other aspect, and in my opinion far more useful part of debug mode, is the removal of code minification. You could be forgiven for thinking that any custom lightning component code written for Salesforce is exactly what is served from Salesforce servers straight to users, but this is not the case. For Aura Components, the code is barely tweaked. So this point is not too relevant to them, but for Lightning Web Components (which includes the ones Salesforce use themselves to build up Lightning!) have all their codes modified to reduce the number of characters present – this is done to reduce the size of the files and as a result, decreases loading times “making it Lightning fast!”.
Image: how am I supposed to read this? Taken from Chrome’s sources or Firefox’s debugger tab.
When turning on debug mode, the code served hasn’t undergone this minification process, so the code is more representative of what was actually written by the developer, just with some additional lines provided by the Lightning Web Component framework. Since the code hasn’t undergone this minification process, the actual file server can be much larger. So one of the major downsides of debug mode becomes apparent – everything is much slower when debug mode is on, hence you should only be using it when actively debugging or developing.
How to Use Debug Mode
So now we know what debug mode does. The next step is making it work for us. As previously stated, the major benefit of running in debug mode is the removal of code minification across our own LWC code, and Salesforce’s own platform code. In practice, the biggest advantage is that the big red scary error messages actually begin to make sense, no longer having stack traces that look more like equations written to take somebody to the moon. You can expect the error messages to look far more familiar (although there’ll still be a bit of waffle in there!).
Image: who invited Mr T? I wish I knew what this meant….
Image: with debug mode on – much easier to understand!
As you can probably imagine, when an error message looks like an error message, you’ll have a far easier time identifying the pesky problem and squashing that bug once and for all, when you combine it with the swiss army of debugging, browser debugging tools (see Mozilla Developer Network or Googles documentation on their JavaScript debuggers depending on your browser of choice for some invaluable further reading).
Final thoughts
While no debugging tool is a magic wand that can be waved across your org to make all your bugs disappear, debug mode should definitely be one of the tools in your toolbox when bugs hinder your progress. It allows you to review what’s going on in a more familiar and understandable format. Although it is a wonderful tool, due to the most notable downside of using it (reduced performance), like a hammer, you should only wield it when required, or you’ll risk causing yourself unnecessary troubles.