Using DOM Breakpoints with Chrome DevTools
How to increase productivity by using DOM Breakpoints
DOM Breakpoints is one of the latest additions to Chrome DevTools. It allows developers to put Breakpoints directly on DOM elements to monitor state changes.
In this article, I will demonstrate how to use DOM Breakpoints, evaluate different types of Breakpoints and their features.
Using DevTools for DOM Breakpoints
In Chrome DevTools, you can add DOM Breakpoints easily by clicking on top of an element.
The steps will be as follows;
- Right-click on the element.
- Select
Inspect(Elements tab will open with the selected element highlighted). - Right-click the highlighted HTML.
- Go to
Break onand select the type of breakpoint.
You can find all the breakpoints listed under the ‘DOM Breakpoints’ tab. And, let’s look into different types of Breakpoints to understand how we can use them in practice.
Types of DOM Breakpoints
1. Subtree Modifications
Subtree modification Breakpoints will break the execution of any event whenever a child element of a selected node is modified. The modification can be a removal, addition, or change in child content.
In this example, I added a subtree modification breakpoint to <ul> so that it will hit the breakpoint whenever I add a new <li> the element inside it.
We can see that after hitting the breakpoint, DevTools immediately points to the line responsible for the modification of the DOM. Then we can navigate through the function line by line using controls in the JavaScript debugging pane.
2. Node Removal
As the name implies, Node Removal Breakpoints are triggered when an element is removed from the DOM tree. Using the above example, we can remove an item from the list by clicking on it.
Here I added a node removal breakpoint to an <li> element. As a result, the application flow breaks when the list item is clicked, allowing us to resolve bugs.
3. Attribute Modifications
Attribute modification Breakpoints are used for debugging changes to attributes in an element. They are triggered when an attribute is changed, added, or removed.
Let’s change our example to style the text of a list item whenever it is clicked.
When the <li> element is clicked, a new class is added to change the style to font-weight: bold and text-decoration: line-through. Since the class attribute is modified, the breakpoint is triggered.
But, I’m sure some of you might wonder whether it’s just an alternative to code level Breakpoints and does it add any value for web development?
Why use DOM Breakpoints?
DOM Breakpoints are new to many developers, and let’s look at the benefits it provides for frontend developers.
1. Increase efficiency
When we debug any frontend code, we must know the code lines responsible for the resultant action. We typically look for it in the script plane by searching from the file name. However, if you don’t know the file name, it takes time to find the exact match.
But, it’s not that difficult to observe the UI state changes that happen due to the code execution. Therefore in some cases, it makes more sense to start from the DOM putting Breakpoints and find the relevant code straight away.
Therefore, DOM Breakpoints increases the efficiency in identifying issues in code that links with UI state changes.
2. Reduce the need for console logs
As a general practice, most of us use console.log for debugging the code execution paths. And, sometimes, it takes more time to put them and observe the log sequence and variable value we print in the console. Besides, it also needs additional effort to clean them after its use.
And with DOM Breakpoints, you can minimize the need for these logs since you have two directions of debugging the code flow and observing the variable state.
3. Real-time debugging
If you are using the traditional debugging methods, you might have to stop the application, make changes, and reload or wait for the live reload to kickoff. Sometimes, opening a large script in DevTools to find the relevant code line could become slow.
But using DOM Breakpoints with DevTools will help you find the relevant code block while the application is running.
Build with independent components, for speed and scale
Instead of building monolithic apps, build independent components first and compose them into features and applications. It makes development faster and helps teams build more consistent and scalable applications.
Bit offers a great developer experience for building independent components and composing applications. Many teams start by building their Design Systems or Micro Frontends, through independent components.
Give it a try →
Final Words
Using Breakpoints is the most effective approach for debugging. With the introduction of DOM Breakpoints, Chrome DevTools has gone the extra mile by providing multiple avenues to debug any code segment.
So far, there are three types of DOM Breakpoints provided by DevTools. These are subtree modifications, attribute modifications, and node removal. We can use these types to track different changes to the DOM and find the code lines responsible for each of these modifications. As a result, you do not have to get into the hassle of going through the code lines manually to find where the DOM event is handled.
I hope you will try out DOM Breakpoints in your future development. If you have any questions, please mention them in the comments below. Thanks for reading!!
