阅读 5116

【译】你不知道的 Chrome 调试工具技巧 第十二天:忍者日志打印!(the ninja logs)

特别声明

本文是作者 Tomek Sułkowski 发布在 medium 上的一个系列。据作者透露一共有 24 篇,一直更新到 12 月 24 日
版权归原作者所有。

作者在Twitter上推荐我们的中文翻译啦,截图在最后

译者在翻译前已经和作者沟通得到了翻译整个系列的授权。
为了不影响大家阅读,授权的记录在这里

正文

在马上就要迎来假期的这 24 天里,我将会发布一系列短篇的文章,关于如何更加有意思的使用开发工具,昨天我们深入了样式编辑器,今天我想展示一个我称之为 ninjia console logs 的有趣的技术,但是首先我们先谈谈...

33. Conditional breakpoints 条件断点

有时设置的断点被执行太多次了:想想看,有一个对 200 个元素的循环,但你只对第 110 次循环的结果感兴趣,或者只对一些满足其他的特殊条件的结果感兴趣。

这样的情况下,就可以设置一个条件断点。实现:

  • 右击行号并且选择 Add conditional breakpoint...(添加条件断点) 的选项

  • 或者右击一个已经设置的断点并且选择 Edit breakpoint(编辑断点)

  • 然后输入一个执行结果为 true 或者 false 的表达式(它的值并不需要明确的为 true 或者 false 尽管那个弹出框的描述是这样说的)。

在这个表达式中,你可以获取到任何这段代码可以获取到的东西,即这一行的作用域。

现在条件满足的话,断点就会暂停代码的执行

34.The ninja(忍者) console.log

得益于条件断点,现在可以开始灵活使用这个技术。 因为:

  • 每一个条件都必须经过判断 - 也就是 - 运行 - 每当应用执行到这一行。
  • 并且如果条件返回的是falsy的值(例如. undefined ),它并不会暂停..

所以,与其在源码的不同地方去添加 console.log / console.table / console.time 等等,不如直接使用条件判断来将它们 “连接” 到 Source 面板中。它们不会停止,会一直执行,并且当你不再需要它们的时候,有一个地方( Breakpoints section )会列出它们。点两下鼠标就可以把所有的都移除,就像一堆忍者一样消失!

这个技术在调试生产环境的问题时同样很有用,你可以将 console logs 轻松插入到 source 里。

今天的分享就到这里~

惯例: 如果你从这里学到了一些新东西

→ 你可以点个赞再走嘛~
→ 关注我:Twitter:Tomek Sułkowski

其他系列

其他此系列的文章,马上就会翻译出来,到时会贴出对应的链接在此处。

写在最后

如果你对我的翻译表示肯定,也可以关注我一波哦~ 顺便我的开源项目,求一波 star→ 看这里, 美丽的博客系统

作者在Twitter上推荐我们的中文翻译啦

关注下面的标签,发现更多相似文章
评论