Transcript from the "Debugging with VS Code & Chrome" Lesson
[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: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.
>> Burke: I'm gonna go ahead and select.
[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.