Another way of achieving this without searching through the source in the browser is, in your editor, to type:
debugger;
at whatever point in the code you want to step into.
e.g.
import{Component}from'@angular/core';@Component({selector:'app-root',templateUrl:'./app.component.html',styleUrls:['./app.component.css']})exportclassAppComponent{author=getAuthor();debugger;// <-- heretitle=`my-app by ${this.author}`;}functiongetAuthor(){constobj={name:'songthamtung'};returnobj;}
(though, don't forget to remove any debugger lines you've added after you've finished debugging!)
Breakpoint can be disabled or attached with some condition. There is no way to control debugger;. To me it has some value only in case if you have access to source code but browser executes minified code(without source maps) so it's really hard to find appropriate line to put breakpoint.
The discussion was about whether or not to use console.log (where you need to be working with source code anyway) so debugger is a useful alternative in this case. For a production build, it would be common practice to minify and uglify the code - stripping out all console logging and 'debugger' statements. So, in that regard, yes, you are correct - this would not apply to a production build scenario.
Obviously, your tools and approaches will vary according to the situation. It's helpful to be aware of all approaches and use as you see fit.
Another way of achieving this without searching through the source in the browser is, in your editor, to type:
debugger;at whatever point in the code you want to step into.
e.g.
(though, don't forget to remove any debugger lines you've added after you've finished debugging!)
Thanks for reading and sharing another alternative Kyle!
I had no idea about this feature.
I just tried it and it automatically brought me to the
debugger;breakpoint in devtools. 👍Breakpoint can be disabled or attached with some condition. There is no way to control
debugger;. To me it has some value only in case if you have access to source code but browser executes minified code(without source maps) so it's really hard to find appropriate line to put breakpoint.The discussion was about whether or not to use console.log (where you need to be working with source code anyway) so debugger is a useful alternative in this case. For a production build, it would be common practice to minify and uglify the code - stripping out all console logging and 'debugger' statements. So, in that regard, yes, you are correct - this would not apply to a production build scenario.
Obviously, your tools and approaches will vary according to the situation. It's helpful to be aware of all approaches and use as you see fit.
wow! Thank you for this tip!
And, as it often happens in life... 2 hours after reading your comment, I stumble on this tweet: