Code with an animated lightning bug crawling over it

Lightning Component Debugging Tips

Lightning Component debugging and troubleshooting can be challenging. Throughout the years, I have found myself using some of the same strategies over and over. This article describes those strategies that I use to debug Lightning Components using the Google Chrome browser.

Set up the Environment

There are two things that you want to do before you attempt to debug any Lightning Components: turn on debug mode and turn off caching.

Turn on Debug Mode for Lightning Components

This will cause the aura_proddebug.js file to be served instead of the minified aura_prod.js This is done on a user by user basis, so that whoever else is using the system is not affected. The control for enabling/disabling debug mode on a user by user basis is under Debug Mode in setup.

Turn off Caching

When you make changes during development, you want to see them immediately. When caching is enabled, you may make a change, refresh the page and not see it. Once you turn off caching, you will see the changes immediately. The setting to enable/disable caching is under Session Settings in setup.

Console Logging

The Lightning Component bundle controller, helper, and renderer are JavaScript, so you can take advantage of that and use console logging. The easiest type of console logging is to just output some string or value or object.

Additionally, there are other console logging methods documented in the Console API. The table method can be especially useful. It will output an array of objects as an HTML table in the console.

The one issue with logging is that the Locker Service uses standard Proxy objects, so when you try to drill into them, you don’t really get any useful information.

There are a couple of ways to deal with that. The easiest thing to do is to just use the JSON JavaScript Object and stringify the object, parse it, and output that. You can then drill into it in the console.  If need be you can just stringify with no parsing and copy the text to a JSON-aware editor for formatting.

Alternatively, you can write some simple code to get at the fields as noted in this StackExchange answer by Mohith Shrivastava. There have also been rumblings of making the debugging easier around Proxy objects, so hopefully that eventually comes out.

Framework Console Output

Some error messages emitted by the framework, itself, can be useful. If you see that a component is not working correctly, it may be useful to open the console and reload the page to see if the framework outputs any error messages. I have seen this be particularly useful when working with components that rely on the Lighthing Data Service. For example, if you by accidentlly specify a non-existent field for a lightning:input/output field, or mess up the fields array attribute, it will just not show up on the page. If you open the Chrome DevTools Console and look at the output, you will see a clear error message stating that the field was not found.

The above component has a fieldName of Emaill (double ‘l’). Unfortunately this still saves and becomes a run time error. The result is that the field just does not show up on the page. However, when viewing the Chrome Console, a good error message is emitted by the Lightning framework. It is easy to commit this error with any component that requires a list of Strings such as specifying a fields array for lightning:recordEditForm.

Or, maybe you aren’t seeing error messages appear in your lightning:recordEditForm. The framework outputs the following, reminding you to add your <lightning:messages/> component.

Interactive JavaScript Debugger

Chrome DevTools contains an interactive debugger. You can easily set breakpoints in your Lightning JavaScript code by using the debugger statement. Make sure that you have the Chrome DevTools Console open so that the debugger executes. Also, once the debugger has stopped at a breakpoint, you can farily easily see the rest of the component’s generated JavaScript source and set breakpoints directly from Chrome DevTools.

Once the debugger pauses you can then hover over certain items or you can type into watch expressions. It can be useful to add statements to watch expressions to get at specific information that is not in the code. For example, you could output a field value.

Again, the Proxy object may get in the way and you can use the JSON.parse/stringify method in the watch expression.

Another useful feature of the debugger is to set it to “pause on all exceptions”. In this way, if there is some sort of exception you can get directly to it and follow the stack trace back until it, hopefully, makes more sense to you.

Use the Chrome Debugger to Learn APIs

I always suggest looking at the documentation, especially now that there is the very good Component Library. With the introduction of the Lightning Data Service related base components, lightning:record/View/Edit/Form, new types of objects, such as Record UI, in the User Interface API are being exposed. Additionally, it can be useful to see what data is passed as part of event standard events. You can pull up the official documentation to see what the structure of a certain object should be, but it is very helpful to actually see some real data for it. Here, you can use the debugger or console to view the objects in question and see an actual instance while referring back to the API documentation.


It can be useful to inspect the generated source or to inspect various aspects of the Lightning framework, itself.

Salesforce Lightning Inspector

The Salesforce Lightning Inspector is a Chrome Extension that you can install from its listing in the Chrome Web Store. It has support for seeing the component markup (prior to rendered HTML), some performance metrics, some transaction information, an event log tab for viewing the sequence of events, an actions tab to see the server side actions executed, and a storage tab to see local storage for Lightning applications. One of the particularly interesting/useful things is that in the actions tab, you can override server responses. This can be particularly useful for quickly testing edge scenarios or mock reproducing bugs. Sometimes it is useful to isolate your component when using the Lightning Inspector to focus in on just your component.

Inspecting with Chrome DevTools

I tend to do this when something isn’t rendering correctly on the page and seems like something is off with the CSS. You can right click on the offending element in the page and click on “Inspect”. Once you have your element narrowed down, you can edit the CSS directly by adding rules to the selector. This can also be useful for design, because it allows you to apply different styles directly in the browser and see how they affect the component in real-time, and then go back and add those styles to the CSS file of the component. You can also edit the HTML markup and add or remove classes for this same purpose.

Isolate Your Component

Depending on the situation, it may be useful to isolate your component from the rest of the Lightning Experience to try to debug it. To do this, you can create a Lightning App (.app) and add your component to it. You must remember to extend force:slds in the Lightning App to get all of the Lightning magic. The other thing that is useful about this, is that you can pass query string parameters to the app and use them. In the example below, the recordId can be passed in by appending ?recordId=theRecordId to the query string of the app.

It is also easy to launch the apps directly from the Salesforce Developer Console.

Iterative Remove/Add

This strategy is not specific to Lightning or JavaScript development, but is useful to mention nonetheless. Often times, there are many things happening within a Lightning Component and it is difficult to narrow done problems. The best thing to do in this situation is to comment out as much as possible and then slowly bring back small bits one at a time. Confirm each piece works, before brining in the next piece. As soon as it breaks, you will know that it is likely something related to the last piece you brought in is causing the problem. Closely related to this is the strategy of removing one piece at a time, until it works. As soon as it works, you will know that it is likely something related to the last piece your removed that is causing the problem.


I’ve shared my Lightning Component debugging tips; however, another strategy is to defend against bugs happening in the first place. As they say, “an ounce of prevention is worth a pound of cure”. Writing good unit tests with the Lightning Testing Service and incorporating continuous integration into your development process is a great way to head off bugs before they happen. The Lightning Linter is automatically run when you save JavaScript in components, but you can also incorporrate it from the command line with sfdx. Additionally, this article did not cover Apex (server side) debugging. There is plenty of information in the Apex Developer Guide on Debugging Apex and other places.