Some game changing chrome console features..
Conditional breakpoints
You mark a break point on the code line, and then you specify the condition at which you want the break point to be hit. For example, if a loop is iterating 100 times and you need to analyze the 78th hit, you don’t just let the debugger run for 77 times and then analyze from the 78th hit. You specify the condition “index == 78” and then you run your flow, and the break point would be hit at the 78th iteration and you do your analysis.
XHR breakpoint
Typically breakpoints are put directly on the code lines. How would you track to the point in the code where a particular known network request is being made?
Old inefficient approach:
Have a mouse click break point for the action you know would cause the network call. Step in and step out through the code until you finally find the point where the network call is made.
New approach:
Just add an XHR break point with the URL pattern that you know would be invoked. Then you do the user action and the the break point would have been hit when the network call is made. And you have the call stack to see what code is involved in the call and what needs to be changed.
DOM breakpoints
You want to track which portion of the code is greying that button out.
Old approach:
Event breakpoint for the mouse click/any other user action that resulted in the button greying out and stepping through the code till the button greys out.
New approach:
Point to the button element on the page and add a DOM break point for attribute modifications. Now, have the user do the mouse click and chrome would hit the break point where the attribute is changed, and you have the call stack to analyze why the code did that.
