An introduction to debugging using the Firefox DevTools example, part 4 of 4

First part: getting to know the debugger
Second part: find out the value of the variable without console.log
Third part: call stack


Conditional breakpoints

Breakpoints are powerful tools. However, sometimes it is necessary to “lower the power”. If you need a breakpoint in the body of a loop or function that is constantly called (like a callback onscroll), you can get tired of resuming code execution. It is much more convenient in this case to specify exactly when the breakpoint should be triggered. These points are called Conditional Breakpoints.

If you set a conditional breakpoint, the debugger will pause execution only when your condition is true. That is, if the expression you specified returns true or something similar to true

It’s easier to understand with an example, so open our to-do list app in a new tab (this is also a version specially prepared for the article) and go back.

In the last article, we added a breakpoint to the function addTodo… It worked, but execution would pause every time a task was added to the list.

But what if we need to suspend the execution of the code only if the text of the task contains the word “turtle” (eng. turtle)? Easily!

Click on the line number in the debugger (in our case, this is 24) not with the left, but with the right button mice. In the menu that opens, select the “Add condition” item:

Item
Item “Add condition” in the context menu

Now you can specify the condition title.indexOf("turtle") != -1when the breakpoint should hit:

An expression that must return true for the code execution to pause

Method indexOf()returns -1if the required substring (in our case “turtle”) not found… If the substring will found, the method will return a value greater than or equal to zero, which means the condition != -1 will be true.

It turns out that, according to our condition, the breakpoint will be triggered only if title contains "turtle"… That is, if the text of the problem contains the word “turtle”.

Any expression can be a condition. If you wish, you can even enter a call console.log… Yes, console.log returns undefinedwhich is reduced to false, which means the breakpoint will never hit. But the function will be called! And the message will go to the console. Let’s try.

Add a conditional breakpoint on the 68th line in the same place in the debugger, immediately after the declaration of the variable index, and instead of the condition, enter console.log(items[index].title):

Add a call to console.log instead of a condition

Now, for each deletion of a task from the list, its text will be displayed in the console:

Outputting the text of a remote task to the console

This way we can consolidate our code without adding console.log into the code itself.

True, there is an easier way than using a call instead of a condition console.log – special menu item “Add logging”:

“Add logging” item in the context menu

You only need to specify what we want to output to the console, without console.log:

The expression to be printed to the console

The result is the same:

Outputting the text of the remote task to the console in the correct way

Advice to the topic

It happens that you need to set a breakpoint right in the code, and not in the debugger. To do this, use a special word debugger… Provided that the developer tools are open on the page, the code execution will be paused at the line with debugger:

const addTodo = e => {
  debugger; // Выполнение кода будет приостановлено на этой строке
  e.preventDefault();
  const title = document.querySelector(".todo__input").value;
  const todo = {
    title,
    done: false
  };

  items.push(todo);
  saveList();
  document.querySelector(".todo__add").reset();
};

You do not need to re-enter the breakpoint in the debugger.

See for yourself! Open the debugger version of the app in code in the tab with running developer tools and try adding a task.

The code will be paused even though you didn’t specify any breakpoints. It’s all work debugger


What’s next?

I hope these articles have shown you that there are much more convenient ways to debug. console.log… Once again, use console.log – it’s not a shame, just there are more powerful tools.

To know more on debugging and the Firefox debuggerand also about other features of developer tools, you can on MDN.

By the way, the Firefox debugger is written using JavaScript. The debugger and other developer tools code is publicly available, which means you can participate in its development

If you are not yet ready to participate in browser development, and want to start small, help with the Russian version of the Firefox developer tools documentation. The tasks are different: from correcting typos to writing new articles. Contribute to the development of MDN simple: you only need a profile on GitHub and minimal knowledge of Git.

And, of course, install Firefox, built specifically for developers. Firefox Developer Edition – these are the most current versions of tools, experimental features, a separate system profile so that you can easily launch the browser at the same time as regular Firefox.


Final version of the to-do list app

Similar Posts

Leave a Reply Cancel reply