Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I did not know about the debugger statement until I read your comment: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... . Thank you.


Massively useful! I also recently learned you can right click a line of code in the chrome debugger to add a logpoint - i.e. "log the value of this expression when you reach this point in the code" - so I don't have to manually add console.log statements. Basically the reverse of discovering the debugger statement!


One more trick:

Add a conditional breakpoint with the condition: `value = "someOverrideValue", false` to make the breakpoint change the value when it is reached without actually stopping execution. Great for when you need state changed but the app is always trying to override it. Here's a video from a talk I gave five years ago that demonstrates that: https://youtu.be/uixXOTCNbhs?t=1182


Woah. Now that is incredibly useful.


It's also used by malicious websites that don't like security researchers looking at their source, just to say.


> you can right click a line of code in the chrome debugger to add a logpoint...so I don't have to manually add console.log statements

Thank you, this is the best thing I've learned in 2022.


Next try https://www.replay.io, which allows you to add logpoints to code that has already executed.


You can also right click a DOM element in the inspector and click `store as a global variable`. It will automatically do the following for you

temp1 = document.querySelector(SELECTOR_FOR_NODE_YOU_PICKED)


This was news to me too


It's pretty powerful. I oftentimes struggle to get VS code to pick up a breakpoint when debugging serverless node functions, but the debugger statement usually gets it working.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: