You built your first Lightning web component, everything looks great in the IDE, but something is not working as expected in your Salesforce org. That’s the point where it’s important to know how you can debug Lightning web components. This blog post will show you the available techniques.
Lightning web components in production mode
Before we look into debugging, it’s important to understand how we serve Lightning Web Components to the browser in what we call production mode and what utilities you have at hand for them. That mode is what you experience out of the box when a user uses Salesforce. It provides you two things when it comes to Lightning Web Components:
- Proxied values
const mySuperVariable can become
Without any special setting, you can use the pretty format option in Chrome DevTools (or similar counterpart in your preferred browser) to get some sort of code formatting. This doesn’t give you full readability because of the changed names of variables and functions, but it’s pretty decent for a first check. This code is already debuggable, which means you can set breakpoints, inspect values during runtime, and use Chrome DevTools to work with the debugged values.
Note, that you see in the GIF already the location of custom Lightning web components in the Source tab – it’s
modules (compared to
components for Aura components).
JSON.stringify() in Chrome DevTools (note: if you have an Object with circular references, it’ll throw when stringified), or you have to inspect the object structure itself.
Now, you already get some good debugging information in production mode. But what if you want the real cool stuff? Let’s take a look at that.
Lightning web components in debug mode
Besides production mode, you can enable debug mode for specific users. Debug mode gives you a few things, and particularly a few things that were not available previously for Aura components:
- Custom formatting
- Developer mode console warnings
You can read more about debug mode and how to enable it for users in the Lightning Web Components documentation. You can also use Salesforce CLI to create a new user in a scratch org with debug mode enabled using this command:
sfdx force:user:create -a mydebuguser UserPreferencesUserDebugModePref=true
More information on how to use the
force:user:create command can be found in the documentation.
A tip on debugging data that you receive via decorated properties (@api or @wire): if you bind the decorator to a property you won’t currently be able to debug it. In case you see some behavior that you need to debug, change the property to a function (for @wire) or to a setter (for @api). Then you can debug based on the deconstructed
Custom formatters aren’t enabled by default in Chrome, so you’ll need to set Chrome DevTools => Settings => Enable custom formatters.
Console engine warnings
The third feature we’re shipping for helping you to better debug your Lightning web components are “LWC engine” warnings. In debug mode the Lightning Web Components engine actually identifies bad patterns that are only detectable during runtime, and then prints them as console warnings.
It’s a best practice to develop your Lightning web components in an org using debug mode. That way you see if your code can be even more improved while you develop.
There’s one caveat at the time of this writing: you’ll likely see other console warnings from the LWC engine on the console, as we with the initial release don’t filter on your own namespace. Because of that, you see other warnings for things like base Lightning components. Also note that in the current version of the filter in Chrome DevTools has no effect on the logged warnings themselves. Some of the warning messages are also obsolete and will be removed soon, like
Property “xyz” of [object] is set to a non-trackable object, which means changes into that object cannot be observed (meaning you don’t have to care about that at the moment). And yes, we’ll improve that in the next few months (#safeharbor).
The best way to actually filter for only your own components is to remove the “info” log level which hides the stack traces.
Pausing on caught exceptions
Check out the video walkthrough
All the information of this blog post is also available as a short walkthrough video in our newly launched Lightning Web Components Video Gallery.
If you want to learn more about how to use the Chrome DevTools, check out the documentation. This website also contains a lot of useful tips to make you even more productive with Chrome DevTools. Once you’re ramped up, you should try your newly gained knowledge by deploying one of the Lightning Web Components apps from the Trailhead Sample Gallery.
Another important element that we haven’t yet discussed is how to actually unit test your Lightning Web Components functionality before you deploy them, so that you may not have to debug your code at all. We’ll cover that in an upcoming blog post.
About the author
René Winkelmeyer works as Principal Developer Evangelist at Salesforce. He focuses on enterprise integrations, Lightning, and all the other cool stuff that you can do with the Salesforce Platform. You can follow him on Twitter @muenzpraeger.