DevTools tips — day 16: breakpoints
part of the “Advent calendar for front-end developers” series
Over the 24 days leading to the holidays I am publishing short articles with tips on how to use DevTools in more performant and fun way. Yesterday we’ve had some “guest tips”. Today let’s look into some ways to trigger a breakpoint.
45. DOM breakpoints
Is Some script changing a part of your DOM and you’re not quite sure which one or when? Add a DOM breakpoint. You can listen to node being added or removed, or its attribute being changed:
The breakpoints are remembered between page reloads. Once you’ve set up one — or a couple!—of them, you might forget where specifically they’re attached. How to find them? There are visual cues in the Elements view and a dedicated list in the Sources for this very purpose.
And don’t worry if the element you’ve attached a breakpoint to is hidden in some collapsed parent ancestor element—it will still show in the Element, just in a lighter color.
46. MutationObserver
This tip is not exactly related to DevTools but since it’s a nice expansion upon the previous one, I hope you can forgive me this digression.
Anyways, did you know about MutationObserver? It’s an object that’s just a part of browser API and allows to listen to similar changes as the previously mentioned DOM breakpoints do: childList, attributes and subtree — but this time from your JavaScript code.
And it’s actually quite well supported, starting with IE11.
47. XHR/fetch breakpoints
If you want to catch the specific moment an “ajax” request is being sent, use this XHR/fetch breakpoint. These you can only set up in the Sources panel (I’d hope for Network panel as well, but that doesn’t seem to be the case).
You can add a partial URL as a trigger or listen to any request:
And that’s it for today! As usual, if you’ve learned something new, please:
→ clap 👏 button below️ so more people can see this
→ follow me on Twitter (@sulco) so you won’t miss future posts:
Also, the 17th day is already published, read it here:
