Debugging with VS Code & Chrome

[00:00:00]
>> Burke: Let's talk about debugging browser apps. I love this subject. So I would like to propose to you that JavaScript and web developers have the distinguished, what's the word? The distinct capability or position of writing code in one place and debugging it in another. Can anybody name me any other platform where you write code in one place and then go somewhere else to debug it?

[00:00:32]
I don't think it exists. So what I mean by that is we write apps and then we go to Chrome and we open the DevTools and we debug in there. The reason why we do that is because it's a zero setup debug environment, totally understandable. But here's the thing.

[00:00:45]
If you can get your browser apps to debug in your editor, it's a way better experience. Would you not want to debug your code in the same place where you write it? You do, absolutely. So what we're gonna do in this next one is do that with Chrome.

[00:01:02]
So let's go ahead here and open up a launch configuration for our debug browser apps. So I'm gonna hit the drop-down list, I'm gonna add a config.
>> Burke: And I'm going to make it Chrome. And I'm gonna make sure that I have the correct settings here. So I'm gonna just call this one Launch Project 3, so I know which one I'm working with.

[00:01:28]
And anybody see anything else we need to change? Can you see it? Anybody getting ideas?
>> Speaker 2: The ports.
>> Burke: Ports, that's right, that's not gonna work. What port are you running on?
>> Speaker 3: 3000.
>> Burke: 3000, that's right. And then we need the webRoot, which is workspaceFolder, which is right.

[00:01:46]
The URL is correct. And really, we shouldn't have to do anything else here for this to work. I'm gonna go ahead and open up the terminal and add another terminal instance here. Now, the app that I'm running here has to be started with MP, so here's the thing.

[00:02:03]
VS code when it opens Chrome is gonna open another instance of Chrome because it has to pass in a flag to Chrome, that says, open in debug mode. By default, chrome doesn't do that. So what we wanna do is wanna start this thing, so let's do that. Here we go.

[00:02:20]
So now we're running, and we wanna debug this. So let's go ahead and make sure we've got the right thing selected, Launch Project 3. And I'm gonna go ahead and hit the debug. And you're gonna get a second instance of Chrome. And so we get two instances of Chrome open, right?

[00:02:35]
One is debug mode. One is regular Chrome. We can close this if you get confused, this is the one we're working with. And now we can add a break point here in our app.js file. So we're using SignalR to retrieve updates whenever the colors change. I don't know if you noticed this but in your app if somebody else changes the color, your app changes too.

[00:03:00]
And the reason that works is because there's a service called Azure SignalR that I've tied into. And basically anytime somebody updates the color, I send that through SignalR, SignalR are connected to all of you, by virtue of you opening a connection with JavaScript, and it's updating everyone at the same time.

[00:03:14]
It's just a real time update service. We can intercept the message coming back from SignalR by putting a breakpoint here. Notice that I tried to put a breakpoint on the comment, and VS code did what? As like now, you mean this, it moved it down one for me.

[00:03:31]
It's trying to help you. Thank you VS code. Alright, so we've got a breakpoint here. So if somebody changes the color actually, and in fact, it doesn't have to be me. It should be able to be anybody that's got the app up and running that can make a call to the API that changes the land color.

[00:03:50]
>> Burke: I'm gonna go ahead and select.
>> Burke: And it's now broken inside of, VS code, but this JavaScript is running in Chrome. So we're now debugging our browser app inside of VS code. This is all browser code here, all of it. Now, here's what's even more interesting about this.

[00:04:14]
If we come back to Chrome, what does it say up top? Paused in Visual Studio Code. It's like they know each other. And check this out, if we open the DevTools, look at that. Guess what? It's broken in the Chrome DevTools too. The reason why this is cool is because you can seamlessly move between these two environments.

[00:04:36]
You don't have to give up one set for another. And in fact, let's just say we added a break point here, okay? And then we continued on in Chrome. What do you think's gonna happen?
>> Speaker 4: It hit the break point.
>> Burke: It's gonna continue on in VS Code and it's gonna hit a break point that doesn't exist in VS code, but it exists in the Chrome DevTools.

[00:04:57]
So you see how these two things work together and make for a very powerful debugging environment. Debugging browser apps is a very different, interesting, and unique way to think about your JavaScript. We haven't had this capability so far as Frontend web developers.