Mastering Chrome Developer Tools v2 The --inspect Flag
This course has been updated! We now recommend you take the Introduction to Dev Tools, v3 course.
Transcript from the "The --inspect Flag" Lesson
>> Jon Kuperman: Next thing, really cool. So I mentioned earlier that now Node seamlessly integrates with Chrome dev tools. So this is pretty recent. There's been third party projects for a long time that do it, but it's now natively established. And so, if we kind of go over to here and we, basically, the idea is you go into your terminal wherever you are running node from.
[00:00:26] Like here I've been running mastering dev tools. So normally I'm running npm start and that's how I'm starting my server. If we look in the code at what npm start does, it just runs node server/index.js. That's all, it's really just an alias for that. So if I did node server/index.js, it would do the exact same thing.
[00:00:45] What you can do now is you can do node with a --inspect flag, and then you can do server/index.js. And so what that's gonna do for you is it's gonna start this over just like normal. So if I go and I refresh here, I still have my server going.
[00:00:59] But now when I open the dev tools, I see this new icon here. It's the Node.js logo up in the top left. And so if I open the dedicated dev tools for Node here, it opens them up and we can see I've got a bunch of different options over here.
[00:01:12] So we can do memory stuff. We can look at sources. We can look at console. We can make sure our connection is still working and then we can do a profile. so one concept that you can do to just kind of see how your Node app is working is you can start a profile.
[00:01:28] And you can go to your page, and just refresh the page, and you can go back to the profile, and just hit Stop. And so what this is going to do is this is going to show you, as that refresh happens, remember this isn't looking at your front end assets anymore.
[00:01:39] So you're not gonna see the network calls, you're not gonna see your CSS, your jobs, none of that stuff. What you're gonna see is what the actual back-end application does. And so what it does is, it generates, let me just zoom back out, it generates this flame chart.
[00:01:51] And these are a little bit tough to navigate. The kind of concept is that as you scroll, it'll zoom in on a certain area. The x-axis is time. And so you'll kinda scroll in on an area and then you'll start seeing all these different color boxes with code in them.
[00:02:05] So you'll kinda keep scrolling in on that area and here we go. And this is basically like an x-axis is time and then the y-axis is the call stack. So it's like, get started with an anonymous functon, call another one, calls this next function, calls this, calls that.
[00:02:19] Cutting back to our debugging example. One called two called three called four. You would see those top to bottom. So a long call stack is nothing to worry about, just a bunch of functions calling each other. But a wide call stack is something to worry about. Why did it take as long as it took?
[00:02:33] So we can see at the top. That the self time, the total time, rather, was 36 milliseconds. That is super fast, nothing to worry about there. But, if we see one that's longer, like a second or something like that, we wanna drill into what it is that took so long.
[00:02:47] One thing you might notice is you try to scroll down here and just keep zooming. So if you wanna scroll up and down, what you'll need to do is hold the Shift button and you'll scroll down. And that you can see all these things call each other and they kind of split off in a different call stacks.
[00:03:00] The kind of quick view of how to use this thing, how I use it anyway is, you wanna so the wide ones are long. But every function is gonna be as long as all of it's children right? So if you have like a function that does almost nothing, but it calls another function and that function has to wait for five seconds.
[00:03:17] Both of them will be seen as five seconds, cuz it took five seconds for them to complete. So what you wanna keep in mind is you wanna find the last long one cuz you're going down, all right. So you don't care about the pairing, you wanna see what the last thing was that took us super long time, but it had children that didn't take a long time.
[00:03:31] Does that kind of make sense as a way to think about it? So what I'm looking at here, is like the thing that took the longest by itself is this compiled body. That's what took the longest, cuz it's the last one before they break into smaller ones. I can see that load string and generate code took a pretty long time, but my slowest function is compiled body.
[00:03:47] That's the one that took the longest time. So you can kinda click through. You can start seeing it'll take you to the actual node code now, cuz now you're able to actually access all that node. And yeah, you can see all the code that's running. So this works for a web server.
[00:04:00] This works for command line application. This works for if you like webpack and you wanna see how it performs, you could just run node dash session inspect next time you run web pack and see all the cool stuff it does. Same thing with any of your node apps.
[00:04:13] So it's really cool. Any questions on how to kind of get that going, so it's with the dash dash inspect flag, and then it gets you a new dev tool. Cool.