Debugging Angular applications

— What’s developers do most of their time?
— Debugging.

As developers we spend hours on fixing different errors, sometimes we don’t know what they are and how to fix them. In the article I’m going to list some different debugging techniques I know and use on the daily basis.

0. Stop panicking and read the error message

Most of the encountered errors are simple and their messages describe clearly what went wrong and how to fix it. For example

here we have an infamous ExpressionChanged error. It states that the value was “Angular 13” and then it became “test” after check. If followed to the docs you can find that most probably it’s because of AfterViewInit hook changes. And this is where the value mentioned in the error message comes from. So if we move it to the ngOnInit hook it gets fixed. Also, in browser’s console it points to the place in the template where the issue was found so it’s also usually clear what property was updated.

1. console.log

If the code misbehaves you could put log messages in multiple places to quickly follow the flow in the console

...
someMethod() {
  console.log(1)
  this.httpClient.get(...).subscribe(
    (data) => console.log({data}),
    (error) => console.error(error),
    () => console.log('completed)
  )
}

This is usually useful in checking small scenarios where we can use 1, 2, 3 etc. to check the order of execution and log values.

2. console.trace

Another case is when we have some piece of code that we see being executed but we don’t understand why. For this case we can use console.trace() inside the method and when it gets called we’ll see the whole call stack and find the invoking method.

3. Network tab

Since the apps we build usually talk to servers we make requests and sometimes they fail or our handling fails.

For that purpose we have a great tool called Network tab in the devtools.

Here we have lots of useful filters, one of them is “Fetch/XHR” this is where you’ll find all of your requests to the server with static files requested by the browser filtered out. Another useful tab would be “WS” for those who use WebSockets to see the connections and explore their messages.

When exploring requests we have several important tabs:

• headers — it contains request method, its status and of course request/response headers
• payload — it contains the body of the message that you passed to the server if any
• preview — nicely formatted response from back-end. If it’s a JSON then you can interact with it like with any object logged in the console — expand, collapse etc
• response — raw response from the server

4. Check the file + sources

Sometimes there are cases when you try to add log points, debug points and so on but none of them being fired. That’s the time to take a step back and rethink what’s going on. Most of the times when such cases happen it appears that you either are working on a wrong file, wrong env (e.g. dev env while you put logs on your local machine), build failures (sometimes Angular tends to fail the build while not complaining about it in an obvious way and you don’t know it until check the terminal logs).

To check quickly that you are working on the correct file and build works at the same time you can open the console, press Ctrl(Cmd)+P type the file name and verify it contains your logs included.

You can use elements selection screen, select an Angular’s component, type in the console ng.getComponent($0) and execute it. This will return you the selected component’s instance where you can check if the component’s state is correct and reflected in the render

Note: ng.getComponent is available only in dev mode

Also, we have some other useful methods on ng object

We can even use this to manually trigger the change detection and update the UI from the outside

5. Debugger

We can use debugger to put breakpoints in the code so that execution will stop the flow on them and we could check the sate, do some changes etc. For this we need to find our file (Ctrl+P) and click on line we want to put a breakpoint on. To continue the flow we can click on the arrow next to the blue one to see where we get after this line execution. The play button will continue the unpause the execution and continue the flow.

However, this is not all what debugger can give us. If we right click on the line number we will discover a menu with some useful options.

Logpoint is an analogue of the console.log with a difference that you don’t need to rebuild the app when used. Inside it we could use console.trace in order to see the call stack trace.

Conditional breakpoint does what it says. You define some condition so the JS will stop the execution only when the condition is met.

6. Angular devtools

Install the devtools extension developed by the official Angular team. After doing so you’ll find a new tab in the devtools called Angular.

Here we can explore the components tree, their states, get to their source code (angled arrows in the top right corner).

7. Read the stack trace

Oftentimes it occurs that the error isn’t that easy to understand. You read the message, but it doesn’t make any sense, Google gives nothing.

In this case I can advise to carefully go through the stack trace following what was called where. In most of the times you can bluntly guess what the cause of an error just by looking at the file in the stack.

That’s it. I hope it will help you improve the speed of debugging and expand the margin of errors you can solely understand, fix and prevent in the future.