One of the biggest parts of development? Debugging. Whether you're fixing existing functionality or building a shiny new feature, it's pretty common to stumble into unexpected errors — like tripping over Lego bricks in the dark. And to figure out what's causing those errors, you’ve got to roll up your sleeves and dive into debugging with various tools and techniques. In this article, we’ll take a look at how to debug Lightning Web Components (LWC) without losing your mind.
LWC Minification and Proxies
Usually, when you're debugging client-side apps outside Salesforce, it’s straightforward — just toss in some breakpoints, debugger statements, or the good ol’ console.log. But try that in a Lightning Web Component and... surprise! Some things just don’t work — like debugger doing absolutely nothing, or console.log giving you back a mysterious “Proxy” structure that’s about as helpful as a fortune cookie. There are two big reasons for this weird behavior. First, the LWC code that loads in your browser isn’t exactly the code you wrote in your Org.
It’s in Production mode. That means it’s optimized, “minified,” and basically squished to make it smaller and faster. Not only that, but if you manage to find your component’s code and drop a breakpoint in there, it won’t stop execution — so you’ll never hit it.
And the second culprit? Proxies.
In the LWC framework, Proxy objects are used to cloak the internal values of JavaScript properties and prevent updates from outside the intended scope — kind of like secret agents guarding your variables. Cool for security, not so great for debugging.
Debug Mode
So, we can’t really debug our app properly while it’s running in Production mode — it’s like trying to find your keys in the dark while wearing sunglasses. To fix this, we need to switch the execution mode to “Debug Mode.” In this mode, Lightning Web Components become a lot more talkative in the DevTools console, the code loads in its original, readable format, and — best of all — you can set breakpoints that actually do their job. You can turn on Debug Mode by checking the “Debug Mode” box on your user record or enabling it in the Debug Mode Setup page.
After a quick page refresh, you’ll see a helpful little banner at the top telling you that Debug Mode is now on — think of it as Salesforce giving you a high-five.
Now, if you peek at the source files in your browser’s DevTools, you’ll notice the code looks much more like what you actually wrote and deployed to the org.
Even better, you can drop breakpoints, pause execution, and examine exactly what’s going on in your component at a given moment — like a freeze-frame in a movie. The golden rule? Always debug in Debug Mode, otherwise you’ll be wrestling with the limitations of the LWC framework — awesome for production, but a bit of a nightmare when you're just trying to figure out why your button won’t click.
Custom Formatters
Remember those pesky Proxy objects we talked about that make your console.log output look like encrypted alien code? Bad news — they don’t go away just because you’ve enabled Debug Mode. That’s because Proxies are a core part of the LWC magic — they handle reactivity, wiring fetch results, creation of public properties, and all that good stuff behind the scenes. Sure, you could try console.log(JSON.stringify(<property>)) as a workaround, but then you’re just looking at plain text — no expanding, no deep dives, just the basics.
This is where the Custom Formatters setting comes in to save the day. Just hop over to DevTools → Settings and enable “Custom Formatters” under the “Console” section, then refresh your page like a boss.
This unlocks a whole new level of visibility into those proxy-wrapped objects, giving you much cleaner, human-readable output in the console. Bottom line? Always keep Debug Mode and Custom Formatters turned on while debugging — your future self will thank you (probably with fewer frustrated sighs).
Debug Tips
Wire Adapters
Here’s a slick LWC-specific debug trick that leans on — you guessed it — Custom Formatters. With this setting enabled, you can now easily peek under the hood of your wired functions and properties. Say you’ve got a component with a property decorated by @wire — classic setup.
In the old days (read: last year), if you wanted to debug it, you had to convert your wired property into a function just to get any useful info. But not anymore! Now, you can simply inspect the HTML element tied to the property or function, select it in the Elements panel, and fire $0 into the console like a pro.
Boom — you’ll get a clean view of all wired properties and functions, including their input configs and the data or errors they’re working with.
Unexpected Errors: Catching the Sneaky Bugs
When debugging, your first mission is usually figuring out which module is misbehaving. Salesforce does try to help with its error screens, but let’s be honest—they’re often about as helpful as a GPS that says “you’ve arrived” when you’re clearly in the middle of a parking lot.
Your best starting move? Flip on the “Pause on exceptions” setting in the Sources tab of DevTools.
This handy feature puts a full stop on code execution the moment something goes sideways. While you're in Debug Mode, you can inspect the call stack and variable values right at the moment of failure — like CSI for your JavaScript.
It’s especially useful when wrangling async functions or dealing with Promise rejections as it helps catch errors that might otherwise go unnoticed. And when paired with Debug Mode's source maps, it becomes way easier to pinpoint the exact line of code where everything fell apart.
Callout to Apex Controllers: Spy on the Conversation
When your LWC talks to Apex, things can go wrong in more ways than just obvious errors — sometimes the issue is in the awkward silence (no data) or bad communication (wrong data). Thankfully, DevTools can help you eavesdrop on this conversation.
Keep the Network tab open while your component is doing its thing. As soon as it sends a callout, filter the requests using the keyword "apexaction". That’ll reveal all the Apex requests like a magician showing you the trick. Click on a request and jump to the Payload tab. There you’ll find the Apex class, method, and parameters used — basically, the who, what, and why of the request.
Curious about the response? Pop over to the Preview tab. You’ll see a JSON structure where the actions property stores the results. Heads up: sometimes one request talks to multiple Apex methods. That’s Salesforce doing a little trick called boxcar’ing — kind of like carpooling for server calls. You can check how many rides are in the car by looking at the aura.ApexAction.execute request param.
LWC Performance: Who’s Rerendering What and Why?
If your Lightning Web Components are sluggish, it might be because they're rerendering like they’re on caffeine. Often, this happens due to poor state management — properties changing more often than they should.
But don’t worry, you’re not stuck playing guessing games anymore. Salesforce recently introduced Custom Performance Timings to help developers spot unnecessary rerenders faster than ever.
Here’s how to use it:
- Open the Performance tab in DevTools.
- Click the Record button, interact with your component, then hit Stop.
- Grab a snack while it processes the data (or stare at the screen dramatically).
4. Look for the Lightning Web Components track in the timeline.
Each rerender event will tell you what component rerendered and which properties triggered it. It’s like having night-vision goggles for performance debugging.
(Note: This works only in browsers that support Chrome DevTools Performance Panel extensions, like Chrome or Edge.)
Conclusion: Debug Like a Pro, Not Like a Detective in the Dark
Debugging LWCs doesn’t have to be frustrating. With Debug Mode, Custom Formatters, and the built-in tools in DevTools, you can ditch the minified code confusion and proxy mystery. Instead, you’ll get clear insights, powerful traceability, and maybe even a few high-fives from your fellow devs.
When your tools are set up right, debugging LWC isn’t chaos — it’s control. The breakpoints hit. The proxies behave. The errors show their face.
Your components might not thank you out loud… but silence is golden, right?