Stop and look around: Simple breakpoints - JavaScript Tutorial

- [Narrator] In this video we're going to start using the debugger for real using breakpoints. So, first let's open up our developer tools with Command + Option + I here on the Mac. And I'm going to change the sources panel if I need to and open my index.html file, which is where all the JavaScript for this page lives. Let's scroll all the way to the bottom where my JavaScript is. Here we are. Now what I want to do is pause execution when I execute a swipe on this color box. So I'm gonna set a breakpoint right here inside swipe left, inside the callback function, right there. To set a breakpoint you just click in the gutter on the line number. Now, I can reload and we'll open up the color box. And I'll do a swipe left. Once I do that execution pauses. I can see a little message up top with a resume button and another message over here with another resume button that would let me resume execution, in other words, I've stopped now I can start again. And you'll notice that we have some new stuff highlighted over here in this right side panel. The main thing I wanna call your attention to right now is the scope area. This is where I can see all the variables that are currently defined and what their values are. This is called scope because there are various scopes available. In JavaScript in ES5 a function is what creates scope. So, every time you have a function call you have another layer of scope where there's another set of local variables. In this case we just have one local scope for this callback function, and then the global scope which is the window object and everything that's defined there. But if you're just using ES5 as we're using here you'll see scope anywhere there's functions. Okay, let's set another break point down here in the swipe right area. I'll let execution resume, and then let's swipe right. There we go I can see that I've stopped down here. And again, I can see the variables that are defined. So, now that we've stopped at either of these points I can see what's happening at that point in execution. Like right now I can see that the swipe direction was right and then if I resume and swipe left I can see here that the direction is set to left. Let's resume and refresh the page. Now you can see that the breakpoints are preserved across page refreshes, which is great. So, this will only work inside Chrome obviously. If I were to switch to another browser I'd have to set fresh breakpoints over there. But inside Chrome any breakpoints that I've set will stay the same even when I refresh the page. Now if I were to go and make an edit to the html file so that these script tags moved around or changed, they might shift around a little bit. The browsers do try to keep track of what you've done. And you might get lucky and have them stay in the right spot, but it's something you'll need to watch out for if you start making edits and then go back and check your breakpoints. Now these are breakpoints that don't execute immediately. They only execute when I do whatever this callback function is expecting. We can also set them on things that will execute every time, like say this variable assignment. So, I'll reload, and instantly we're stopped, we see here's my message here. And I can check out what is defined so far. Now you'll notice accidental global is currently undefined because I've stopped the line before the variable assignment actually happens. One thing that's worth noting with setting break points. I'll just resume here. Is that they can be set on executing lines. So, if I remove this breakpoint and then try to set one here on this comment. I clicked on line 301 but the breakpoint was set on line 309 which is the next executable piece of JavaScript. The way that different debuggers handle this sort of breakpoint movement will kind of vary. But it's something to watch out for. You won't always get the breakpoint exactly where you think if it's a place that is non-executing. One more thing about setting basic breakpoints. Now, as I said, any breakpoints that I set here in Chrome are not going to be carried over to the debuggers in other browsers or in other debugging environments like my IDE for example. But there is another way to do this. Gonna clear all these breakpoints out. And let's switch over to my editor. Here I am in the index.html file and if I click over here in the gutter it just selects lines but I can add debugger right here and save this. This is a special keyword that will trigger the debugger in any environment that supports JavaScript debugging. So, let's switch back to Chrome and refresh the page. You can see I have this debugger set here. So, if I open the color box and swipe left, there you go. I'm paused right there on debugger. Now this is nice because it lets me set a breakpoint that will be triggered anywhere. I'll resume this, and if I close the developer tools note that if I swipe left nothing happens. Breakpoints will only be triggered when the debugger is actually open like that. So when you're done with debugging statements like this, make sure to take them out before you ship your code. So, now we've seen how to set breakpoints in different environments and how you can look at the contents of variables at the time that you've paused. But this is not everything that you can do just with breakpoints by themselves. We'll be taking a look at some more features next.