DevTools tips — day 12: the ninja logs

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 looked into style editors, today I want to show an interesting technique that I call “ninja console logs”, but first let’s talk about…

33. Conditional breakpoints

Sometimes when you set breakpoints they get evaluated too many times: imagine a loop going over 200 elements and you are just interested in the one in 110th iteration, or only when some other special circumstances (e.g. combination of values) occur.

In that case you can set a conditional breakpoint. To do it:

• right-click on a line number and choose “Add conditional breakpoint…” option
• or right click on an already set breakpoint and choose “Edit breakpoint…”
• and then enter any expression that evaluates to truthy or falsy value (it doesn’t need to be true / false specifically in spite of what the description in that pop-up says)

In that expression you have access to everything that is available in this place in code, i.e. this line’s scope.

Now the breakpoint will pause code evaluation only if provided condition is met.

34. The ninja console.log

There is one slick technique that you can start using thanks to conditional breakpoints. Because:

• the condition provided there must be checked — i.e. run — every time the application gets to that line…
• and it won’t pause if that condition returns a falsy (e.g. undefined) value…

… you can put console. methods there!

So instead of adding console.log / console.table / console.time etc. in multiple places in your source code, you just “attach” them in the Sources panel using conditional breakpoints. They won’t stop, but they will run, and when you don’t need them anymore, you have a nice list of them in one place (the Breakpoints section) you can remove them all with two click of a mouse. They’ll disappear like a bunch of ninjas!

This technique is also useful when debugging production issues, where you can’t just put console.logs in the source.

Pheew, that was intense! And that’s all 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:

Tomek Sułkowski (@sulco) | Twitter

Also, the 13th day is already published, read it here:

DevTools tips — day 13: objects & functions