Debugging Tips for Angular Developers
Something isn’t working right… Now what? How can you figure out what’s going on quickly so you can fix it? Here are a few tips and tools that may help you when debugging Angular applications.
The first tip has nothing to do with Angular. It has to do with you and how you approach your work.
Small Commits
You should commit often. Did you get a couple of methods all working in harmony? Commit! Did you get the layout the way you want it? Commit!
What does this have to do with debugging? Well, a fundamental step in debugging is asking the question “what changed?”. With small commits it’s very easy to compare against the previous commit. Sometimes we find that what is now broken was something we’ve added. We may want to roll it back and try a new approach. Small commits mean less work to analyze, and possibly have to roll back.
Tool Time!
First, some oldies-but-goodies debugging tools often are the fastest way to figure out what’s going on.
console.log(...);
debugger;
Let’s face it, as ugly and brute-force as these are, they are often quite effective. What does the data actually look like when this line executes? Might give you a clue! Stepping into a complex method might make finding what changes a value unexpectedly easier.
If you’re able to debug your server through VSCode then inline breakpoints work just as well.
And don’t overlook more powerful console.dir() and console.table() to get a nicer view of your data.
Be sure that you have a linter in place before using these. The linter will complain about console and debugger statements, reminding you to remove these statements before committing code that you don’t want in production.
These tools are powerful, but sometimes we need to debug something that Angular is doing because of our code. What is happening under the covers in the DOM? What is the state of our components in the larger context of the application? This can be especially difficult to figure out with a debugger or console.log when we’re talking about large lists of rendered components.
A quick disclaimer before continuing. I’m going to focus on tooling in Chrome DevTools and VSCode. Many of the tools and techniques outlined have either parallel implementations in other browsers and IDEs, or equivalent extensions, plugins, etc…
Chrome DevTools
Chrome DevTools in its native state is a very powerful tool.
The Elements tab lets us see the DOM produced by Angular. From there we can also see how the styles were applied to the elements. We can manipulate styles directly, experimenting until we have things the way we want them, and then easily copy/paste these into our application’s styles.
The Console tab lets us manipulate state, execute commands, and evaluate conditions on the fly.
The Sources tab lets us see the code that’s executing. This is where we land when our debugger statements are triggered. From here we can add watches and conditional breakpoints. Are you debugging a list and only having a problem with one element in the list? Putting a debugger in your template isn’t possible. And putting it in a pipe, it may get hit many times. In some cases, a conditional breakpoint (index = 5) may be just the thing to allow you to stop exactly when the error condition occurs.
The Network tab can help you sort out what data is getting returned from your API’s to your front-end application. My favorite use of this is to prove that it’s not a UI problem, but an API/DB issue. Then I can go back to building beautiful UI’s!
The Performance tab can help you find the bottlenecks in your application and animations.
The Application tab allows you to see Local Storage and Cookies, as well as the PWA environment.
As powerful as all of this is, we can add functionality to DevTools that will help us with debugging Angular specifically.
Angular CLI
Make sure you have @angular/cli installed globally with npm install -g @angular/cli.
Serve your site up, open Chrome DevTools, go to the Elements tab, and select any element with your application prefix, i.e. <app-my-component>. Want to see the state of that component? Switch to the Console tab and enter the following command:
ng.getComponent($0)
We’ve invoked the Angular CLI with ng and called getComponent with an argument of $0. What is $0? It represents the last selected element from the Elements tab (or the handy select element tool at the upper left of DevTools).
Wow! Look at all of that information! Here’s a sample of some state from a real component:
You now have a reference to the Angular component in the browser console! You can browse through the state of the component as Angular rendered it.
Want to know even more? We can do SO much with ng in the browser Console:
I won’t dive into all you can do as that is a whole article in itself. Now that you know it’s there, you’re empowered to really dive into the state of your rendered components!
Chrome DevTools Angular Extension
Here is a great extension to Chrome that allows us to both look at the structure of our rendered app in a more simplified view, but also to profile where performance problems are resulting in frame drops. It adds a tab to your DevTools named “Angular”.
https://github.com/rangle/angular-devtools
The tree of elements allows you to get a high-level view of what Angular is rendering. Clicking an element will show you many details about that element, and double clicking will take you to it in the Elements tab.
You can find details about the implementation of the component directly in the browser:
The Profiler tab in this extension gives you the ability to record the performance of your application. You can see frame drops in red, showing you where to focus attention to make your app more responsive. If your bug is performance related, this is a good place to start. You can get similar information from the Performance tab in Chrome DevTools, but the Angular one is more focused on Angular and change detection cycles and may not be as overwhelming as the DevTools Performance tab.
Redux DevTools
If you’re using NgRx then you really need the Redux DevTools Chrome extension. You need to instrument your project to enable these tools to work. Be sure that your configuration doesn’t enable this extension to work in production, unless you’re not concerned about data leaking!
If you’ve instrumented your project then these tools immediately start tracking every Action dispatched to the Store. You can see each Action, its contents, what the effect was on the store (Diff), and the raw State of the store after each Action.
It’s also a time-traveling debugger. So, if you’re strongly tied to your state, you can actually step forward and backward through the state and see your app change! You could even have someone else export their state, import it into your tools, and your app would reflect their state! (Note: this is a real, yet utopian state I’ve never actually seen achieved in any large application. But it’s cool that it’s possible!)
Tip: You may want to get to the state in our application near to where your bug occurring, then click the Commit button. This will clear the Actions list so that you won’t have so many Actions to sort through after you cause the bug condition to happen. It will be easier to find the Action of interest.
Tip: You may want to experiment with your Actions directly in the tool. You can dispatch Actions directly by using the Dispatcher button. You provide an object that represents your Action, like: { type: ‘[Action]', data: data }.
I’ve only touched to surface on these tools, but you will find many features in them that provide you with real power to see what is going on under the covers in your application.
Write a Unit Test
Often, writing a unit test for something that is failing is a great way to sort out where the error is happening. You’ll be able to execute code in isolation to determine if it is a logic error, a nasty side-effect, over-coupling, etc…
One last tip…
Write Clean Code!
Nothing will make debugging easier than having concise, well-architected, understandable code in the first place. When you can read through your code with ease you will often be able to determine where a problem is likely to exist. You’ll narrow down your possibilities rapidly. Clean code is less likely to suffer from side-effects meaning that you’re less likely to have bugs in the first place!
I hope these tips will help you find and kill bugs in your applications faster! Happy hunting!
Now that you’ve read this article and learned a thing or two (or ten!), let’s kick things up another notch!
Take your skills to a whole new level by joining us in person for the world’s first MAJOR Angular conference in over 2 years! Not only will You be hearing from some of the industry’s foremost experts in Angular (including the Angular team themselves!), but you’ll also get access to:
- Expert panels and Q&A sessions with the speakers
- A friendly Hallway Track where you can network with 1,500 of your fellow Angular developers, sponsors, and speakers alike.
- Hands-on workshops
- Games, prizes, live entertainment, and be able to engage with them and a party you’ll never forget
We’ll see you there this August 29th-Sept 2nd, 2022. Online-only tickets are available as well.
