Full Stack Debugging

Nick Taylor 0:51
So yeah, my name is Nick Taylor. I’m the host today for CF e dot Dev. This is a first monthly stream that you try it out. I’m super excited about it. Just want to thank Brian Rinaldi, me, who’s in the chat there for inviting me on. I’m super excited to do this. So about myself. I’m Nick Taylor. Like you can see, I’m a staff engineer over at Netlify. And if you want to find places where I am on the internet, I just dropped a link here. That’s my website that’s got my blogging, my streaming socials and all that. And I also stream on Twitch at MC dot live, I’ll drop that in the chat as well. So feel free to get a follow there. And also, if you’re not following CFE.dev, yet, give them a follow. Oh, cool. So Oh, into live coding view here. Oh, let’s just bring this in to also my first time using Spring merits a little clunky. Myself. All right. So we’re gonna go over a few things today, here. There’s been many times where I’ve been speaking with developers, and they’re unaware of some mugging tools they have access to. So I kind of want to go through those today. If you’re new to web development, this might be new to you. If you’ve been doing this for a while, you might be super familiar with like console dot log and other console methods. But there’s a lot of other things. So what we’re gonna do is, we’re gonna first start off with some console logging. And if you already know this stuff, you know, we’ll go through it fairly quickly. This is a live stream, live coding. So just like on Twitch, feel free to ask questions in the chat whenever you want to. I’m checking it pretty frequently. So happy to answer your questions. So I’m just gonna go to S code here. And I’m just gonna zoom in a bit here so folks can see. And we’re gonna start off logging here. So you see, right here, what doesn’t matter what thing and right now, I have created a React app in here. So this is the template from V. And this app run. So like, if I come back to the website here. See, this is a standard react site that you get when you first set it up. And if I click on here, see counting stuff. That’s pretty much anything in here. So let’s jump to dev tools. Now, if you’ve never used it, before, there’s shortcuts you can use, I usually a command shift I, Mac, but if you’re on Windows or Linux, it’s Ctrl Shift I. And depending on the browser use, you can use the F 12 key as well. So let’s go to the console here. And let’s clear this. And if we come back here, see that I’ve in this console log here, I can just shrink a few things down here. So you can see. I’ve added this anytime the app renders. So we have react here. So this app will rerender every time you click the button to the counter. Again, that’s not part of the stream. But that’s that’s just how React works.

Nick Taylor 4:45
Hey, Caitlin. Yeah, you’re saying definitely guilty of over reliance. So lots, looking forward to learning. That’s awesome. There’s nothing the first thing I’ll say I’m glad you wrote that in is it’s not bad that you’re using console log, the way I typically console log or the other console methods is, if I kind of know what the code is doing already. Yeah, I’ll zoom in one more, Brian. There you go. Cool. You Yeah, that should be okay. Now. Yeah, I typically console log methods when, you know, I’m pretty familiar with the code at this point. And so it fits really honestly, and did hit this part of the code. And then, you know, I’ll go see if it did or whatever I’m outputting in the console love. When I don’t know what’s going on and upwards, the first time I use it, I’ll probably lean towards the JavaScript debugger, which we’ll get into after but I just want to come back here. And so I’m going to click on here, constantly. So actually, I can zoom it, Misty, let’s do that. Okay. We can see here, I clicking count is that remove that? Okay, cool. Nothing out of here. Okay. Now, one thing, like your point, when is like when you write these console logs everywhere. It might not be super, you know, your tokens, your code a little bit, sometimes, you know, like, maybe you add them rarely, like, Okay, I’ve got this working out, I’m gonna create my pull request, well, I better move off, there’s lots first, there are valid reasons, a lot of concepts in your code, sometimes, but typically, if you’re debugging, usually take them out after. So what we’re going to do now is I’m gonna come here, and come back to VS code here, I’m gonna get rid of a lot. So I’m just gonna put it back was cool. And there we go. And let’s clear this. And so we don’t have a console log anymore. And what I’m going to do is, you can actually look at files in the dev tool. So like, you’re familiar with like VS code, or other browsers, you know, you can use Command P, long as you have focused in the dev tools. And, of course, this is what I always do end up pressing print. So if you press Command P, you can start looking for files. So I’m going to type app dot JSX, which is the following working. And basically, I’m going to add a log in here. But writing in, what we’re gonna do here is, say, let’s go right here. I can zoom in this part, but I’m gonna say, add a log. And what a log is, is, it’s like a constant. But it’s something that you set up in the dev tools. Refresh case, oh, hey, Rico, everything all good. Now, just seeing in the chat there. So this is literally the same thing as doing a console log. But instead of writing your code, if you have the tools open, you can just add logging, I can say, Hello, Kaitlyn, Apple. And I’ll just press Enter. And you’re gonna see, this almost looks like now, I’m gonna come back to the console over here. And now, when I click on Account, the app re renders as its react. That’s just how it works. And you’re gonna see every time I click it, it’s saying, Hello, Caitlin.

Nick Taylor 8:54
Now, the nice thing about these lot points is what I was mentioning is, you don’t necessarily have to have these console logs to the code. So if you’re debugging something, and trying to figure out stuff, I personally find points right for that. Which is super cool. Okay. So we have and come to a lot of there’s other audio evidence I can do console dot table and constant not derived, like objects and stuff. Oh, that’s weird. Yeah, I’m not sure why people were waiting. But yeah, the stream is live. So glad you’re here. Now, hopefully, some people are too, and those other 14. So to reiterate a lot of points when you want to log in, but you don’t want to necessarily your actual source code. So I highly recommend checking them out. This is a feature that was created by code and VS code and electron app. So it uses chromium under the hood, which is what I mean, I mean, our Right now with chromium based browsers, like Google Chrome, and all those, and so basically, log points came from vs COVID, and got introduced into all the Britons are so that’s pretty cool. Okay, I’m gonna remove this now. And I’m back here, I started, you see, there’s let me go larger scale, and the code hasn’t changed. So that’s great. Okay, so we’re gonna look into debugging, and code now. And what I mean, there is like debugging is like a concept of, you know, you’re trying to figure out, because, but there’s nothing hidden JavaScript that is literally debugger, you can essentially, stop in a program and see what’s going on, you can inspect things. And then you can continue. And this is super helpful. Kind of like I was saying, initially, where when I’m not really sure, like what’s going on, or it’s like, it’s the first time I’m onboarding at a company.

Nick Taylor 11:03
And they’re like, here’s the app, there’s a bug that we’d like you to work on. And I have no idea what’s going on, I’ll typically leaning towards the debugger. I’ll still use some console logging, for sure. But this will help me get through things. So again, if I go back here, press, press Command, and I’m going to look for that file, app dot JSX. And I’m just going to give most of the screen real estate because basically, let me close this, just because I’m on wide screens, I want to make sure everybody can see here. So it doesn’t matter what the app is up here in the actual web browser window. So you can see here, I’ve got my funnel again. And so what I’m gonna do now is, I’m going to click on the numbers here on the side, these are the line numbers of file. And I’m going to click on number there, for example, you’re gonna see that it goes blue. It might be a different color in Firefox, I can’t remember, if you’re in VS code, I think it’s blue as well. Might be yellow. But anyways, I’m gonna refresh the app now. And then all of a sudden, gonna see if I scroll up for a sec. The app isn’t loaded yet. I can’t zoom in, unfortunately, but the browser is actually staying paused in the debugger, that little yellow lines, yep. And it’s because I’m in the debugger now. Because I said, Okay, when the program starts to run, the website loads, I want you to stop on this one. So that’s exactly what happened. And now, here, I have inspect stuff. Now, these things I can’t zoom in the popovers. But I think they zoom in. But you can see all of a sudden, you can start inspecting things, you can see, okay, this new state, which is a primitive, in React, and you don’t know react for the purpose of this, but it gives you an array, or a tuple, where it’s got a count, and a set count set counts, what increments the count when we’re clicking the button, and, and the count is the value that currently is. So already the okay the count zero. And then let’s just continue here. So you can click the play button, but I use my function key. So I’ll press f8 to do this to continue. And it runs. And now if I just bring this down, you’re gonna see that the count is zero. Now, I’m going to click again, it’s going to stop, we’re going to see the count one now. Nothing mind blowing about the app happening here, but we can see the count again. And then we can inspect other things here. I’ll see if I can show this. Might need to zoom down. Oh, yes. Okay, so we’re paused in the program. And there’s other things in here. We might not be able to get to all of it today. But we can see here, what’s called the scope. And we can see everything that’s available currently running in Java Scutellaria. In our app, we can see here, the counts one, there’s this function. And there’s some other things here, these, these things aren’t as important right now, this is just stuff from reacting. But the main point here is you can actually see things here in terms of inspecting the application, what’s going on the state it’s in. You can see the Global’s as well. So again, there’s some stuff here from the React. But it’s also stuff like local storage, for example, which is browser on the global window. So these are just some other things you can see. I’m just going to bring this back down again. Okay, so it’s pretty boring right now. stop the debugger. It says count is one. So let’s let this continue. It does it twice something when you’re running react developer mode, so it’s not a bug. Okay, so the counts want, we could click the button again, we’ll see it go to two now. But, you know, let’s do something more interesting.

Nick Taylor 15:21
So we already have these breakpoints. So we already know we can stop the program in a particular place. If you right click on the breakpoint that we’ve added, Bloom kind of sticking out here. This part I can zoom in native operating system, but it’s got a context where you can remove the break, you can edit it, disable it, disabling it is another thing like say, temporarily, I just want to stop there. And I’ll click on the calendar, and you see it’s not hitting. So that’s one thing. The next thing we can do is if I re enable it, we can say Edit. And this used to be able to see because it’s zoomed in. And so we have a few options here out breakpoint, which one is currently we have conditional breakpoint. And we have logpoint. We already saw what was which was just logging console logs, but only when the dev tools are open. But there’s this new one here called additional breakpoint. So we could do something like, I don’t know. Let’s say I’ll say I’m going to create some variable for some reason, but I’ll just say, I don’t know. Nick was here, equals one. And you’re gonna see all of a sudden, debugger. How’s it going? Hey, Judas, are you doing? So you can see now that breakpoint is orange color. And it’s got a question mark. And that’s because it’s conditional breakpoints. I’m just gonna go edit for a second. So I can get this variable now. And I’m going to come in the dev tools. And if we go back to the console, and I’m just going to create this global variables, so I’m just going to say, var liquids here. I’m going to say equals zero. Okay? Nothing special going on so far. And if we look at the breakpoint again, here, we’re gonna say, if Nick was here equals one, that’s when we want to actually stop is the fan. For folks in the chat, I got to see Stefan in person last week, so super excited about that. Okay, so we’ve got our conditional breakpoint here, and I’m clicking around and nothing’s happening. So now let’s come back into the console here, and I’m gonna say in was here, and I’m going to set it. And we’ll come back to the sources here. And I’m going to click here. And then all of a sudden, you see that breakpoint has thought, yeah, no, it was good to catch us fine. So the reason why it’s still it’s not obvious yet is the variable next year is equal to one now. This is super useful for when? Oh, yeah. That’s, that’s me. Let me hide that. That’s me getting used to stream yard. Thank you. Thank you. Great. Yeah. So like you saw, we were stop only when a certain condition was happening. And this is super useful. And like, it’s happened before, like, looping through something that’s happened in React, like, I don’t know, maybe I want to see like, as we’re mapping over things, stop when the key or stop variable is something and that’s the only time I can stop. Because without having a conditional breakpoint, what happens is you have a breakpoint like this, and it’s like, every time you try to look through things, it just keeps doing it and doing it. And it’s just takes a lot longer. Like, think of like the terrible example. But imagine you’re looking through something 1000 times, and you really only want to see what happens to the current state of the program. When is that 999 You ideally don’t really want to have to press EVO continue 999 times so the conditional breakpoints are really great for that. Okay, so let’s let this go. I’m just gonna let it continue.

Nick Taylor 19:35
And again, there’s arrows for for you, or you can even hear there’s it’s, it’s not here right now, but this will turn into a play button. This means is that over something, again, the tooltips show me where I can zoom those in, unfortunately. But these are basically buttons that you can use to step through the code and And I typically don’t use those I use my function keys. And if you’re on a Mac, you can set your keyboard use the function keys by default, because otherwise the end up being, you know, like your volume and stuff. But, you know, everybody does their things differently. But I freeze the function keys when debugging. Okay, cool. So, we’ve seen breakpoints, we’ve seen log points, console, logging, conditional breakpoints. Now, there’s another way you can actually get the debugger to stop. So come back here. Sec. Come back and code. There’s this word called debugger. I can put it I’ll put it in the this keyword has been around since the beginning of JavaScript, as far as I know, cuz I was using because back in the late 90s. So okay, the reason why it’s, if you see that, like red error is it’s a es lint error. It’s just saying you’re not allowed debuggers in the code this is so somebody doesn’t accidentally commit this. But for the purpose of what I’m demonstrating here, this is another way that you can actually get the debugger to work. So you can see here, the app is refreshing automatically, feet, and react. But you can see right away, went to go load the app, and it stopped right here. So I don’t have a breakpoint, like, like I did previously, like, like this. It’s just the literal keyword debugger. And this says, stop the program right here. I typically don’t use this, but there are weird scenarios where I technically can’t explain why it happens. Sometimes, like, I can’t get the breakpoint to get hit like it won’t stop there. Again, I don’t have the technical reason why that happens. But sometimes, if that’s happening, I’ll put an explicit debugger. So I just kind of get into the code, and then start stepping through things. So yeah, so there’s that. Just do one at a time. Okay, yeah, we’re pretty good. Just gonna take a sip of coffee. And again, if you have questions in the chat, feel free to drop them. Don’t worry about being super use than just answering questions as you’re doing things. Okay. And then so you can see here, I’m gonna use the F 10 key here, but it’s the same thing as the buttons down here. Just to show you, if I click the down arrow, it’s going to go to the next piece of code, and so on, and so on. And so this is handy. So like, once you’re like, Okay, stop here. You don’t necessarily want to say, hey, write everything again. So you could, but you might be like, Okay, I’m at the point where I want to start checking out things. So then you can just start going bit by bit by stepping, as it’s called, you’re stepping into things, you can also step over things. So stepping over, it’s different in the sense that like, see, there’s a function here, or actually, I can shrink that, let’s do this. Let’s go back to the code here, I’m just going to create a function here and say, Hello, or actually, it’s not a, it’s not a React, or it’s just a function. And we’re just gonna say, console dot log, hello, thank you copilot. Okay. And I’m going to put it just below the debugger. And we’re going to come back editor. Okay, and I’m just gonna let the debugger run again. And like I was saying, you can see the button here, it’s like a play for you. But I again, the function keys, but you can press the play button here, and it’s gonna run again.

Nick Taylor 24:07
Again, like I mentioned, this is a React app in developer mode, so it runs twice. But let’s see, we’ve got this hello function. So what I’m going to do is I’m going to refresh the page. We’ve got the debugger in. And I’m going to step down to the next piece of code. So you’re gonna see here it comes on to the Hello. And again, just talking about things here. You should be able, you can always use the scope here. There’s also watch where you can add stuff like you can look at window dot local location or locations, get one dot h ref, maybe hooks. This is another part of the debugging tools where you can actually see okay, well what is what is the location a trap? And these are things that can add so yesterday debugging and stops, the watch will apply to whatever you’re currently looking at. So in my case, there’s only one page right now, but I can see what the URL is. That’s just another thing. But what I want it to show is, okay, so we have this Hello, we know it’s going to console log. So if I press F 10, it just went to the next line. And if we go to the console, you’re gonna see it’s that Hello, which is expected. Now, let it run again. Okay, now we’re back. And I’m going to step back to the hello again. But instead of stepping over, think of it literally as stepping over a thing, instead of stepping into it. So I’m going to step in, and you want to step into things when you want to see what’s going on in a function or something. So I’m going to step in now. And then all of a sudden, you’re going to see I’m in the hello function. And this is the code is this is compiling into something else. But this is console log, essentially. But you can see here, I stepped into the code, as opposed to stepping over it, you know, sometimes want to know, a function is doing something already, and it’s fine, don’t want to step into it. So you just step over. So we’ll let that run again. So there’s that as well. Again, if you have questions, go for it.

Nick Taylor 26:30
Okay. So this is all, and we’re in the browser, and we’ve been debugging, and we’re gonna kind of step back, and we’re gonna go to here, stop the project. And I’m just going to create a new file, and call it index.js. And save it. And this is going to be a no JS file now. So I don’t know, let’s see, let count equals zero, trivial example. I know. But you know, for demonstration purposes, that’s just me and say console. And let’s just, okay, nothing fancy. Now, if I want to do this, I’m gonna say node index.js. And you’re gonna see in my terminal down below, which I’ll pop up one more, if you run it, see it console log account. Know, and just to show, if I change that to 400. Again, you’ll see that okay, that’s great. But what happens if I need to debug this? So the neat thing is, so chromium based browsers like Google Chrome, or like, the new Microsoft Edge, and they’re using a JavaScript engine called V8, you may or may not have heard of that. But it is also with Node.js is built with some, basically, you the same engine that’s running in the browser is what is used to run Node.js. And this is important, because show you how to debug an app in Node.js. So and again, all the other things I mentioned before, like, so walked about, that’s all, you can use all that stuff, Node.js to including the blog. So I’m gonna say, no, no, node, dash dash, inspect dash brk. And what this means is I want to inspect, as in debug, and the brk,, brk just means I want to stop immediately. Okay, now you’re going to see this message, you should be able to see I can see it on the screen, you’re going to see that it says, debugger, listening on some web socket for this long URL. Okay, that’s not really helpful to us. But let’s go back to our browser. Let me clear this. Now. You might not have noticed this, but all of a sudden, there’s this green, Node.js icon here. I’m going to click it. It’s going to open up the browser dev tools.

Nick Taylor 29:37
And all of a sudden, I have the same browser tools that I use for debugging. I can use those to debug Node js. The first time I did this, I was like, holy cow. That’s like pretty cool. So the reason why is because we have added stuff but like at the time Like you can literally write notes as programmed in your editor, like some kind of just notepad equivalent, and you conduct the browser. So now, I have literally all the same tools I did before. So I can step in the code. And then it can console log. And here you’ll see a console log to fork. So for me, at least I find that super cool. Maybe you’d have to go in and do all the other things, too. Like I was making a breakpoint, which is a logpoint. Just, let’s, let’s just do that for fun. So let’s add a breakpoint. And let’s change it to a bug. Let’s just a yellow. Enter. Let’s press. Let’s continue here. Okay, my program is OK, my program finished running. So the debugger stopped. But let’s try it again. And if I come back here, okay, you’re gonna see, by run this, it’s gonna console log camp again. But it should also hug YOLO. And it did.

Nick Taylor 31:20
Yeah, no, that’s, yeah, there’s a lot of things. Honestly, in blogging. It’s understandable, especially if you’re starting out with web development, like, especially modern web development, there’s so much to learn these days. So but but a lot of these have been around for a long time. And they’re surfaced a lot better in editors now, which, which we’ll get to in a minute, I’m going to show you how you can deep up code in Node js next. So yeah, these things like, just for some historical context, like, I used to work in Microsoft taxall. And even before that, and Visual Studio, Visual Studio, but Visual Studio and its predecessor, you could actually use the debugger and everything. In, in those editors to like, you could actually debug in Internet Explorer page. I’m dating myself here, but you could actually stopped, like I can show you here in Visual Studio or Visual Studio dotnet. And do all the same things. So these things have been around the time when Mozilla browser previously nets, and then it became a Mozilla browser and Firefox, there were some tools that came out. And if he called Firebug, shadow to fire buckets, great project. It’s no longer required. But you could do all these things I’m showing now. Yeah, basically, as the tools got better, the like dev tooling in general has been like so good. I know people like to complain about things. For me, when web dev tooling space right now. Amazing. And there’s a lot of stuff we might not even get to today, but But getting back to note here. So we’ve been doing No, just plugging in the browser dev tools, which again, I think is pretty. Okay, that’s cool. But like, I’m a fan of VS code, or maybe you’re a fan of whatever editor you see, you know, like JetBrains, WebStorm, or whatever. And they all have debugging capabilities to enable their other editors now. So like, you know, so I’m gonna go and show you in VS code. But like, like I said, if you’re using WebStorm, or something, a quick Google will probably show you like, how to Node.js in WebStorm, for example, and it might even be set up automatically.

Nick Taylor 34:05
Okay, just gotta take a sip of coffee here. If I if I look like I’m melting on stream, it’s because I am. Unfortunately, flooding in my basement last week. I was like this industrial dehumidifier, my basement and it’s causing so much heat. So like, hands on. I feel like my face is melting. So I might have to do this occasionally. It’s it’s not tons of suntan lotion or whatever. Okay, so let’s come back here into VS code and let’s just maybe just add some more stuff here. I’m being lazy, so I’m just gonna use copilot create a loop so it can see the debug or an action. Sure. So Copilot Correct.

Nick Taylor 35:01
Okay. Okay, yeah, sorry. Yeah, in vs. Code debugger. Points are different dots. That sorry. So you can see here, I’ll put one here. And now the first thing you’re going to do is VS code. If you press and shift D or Ctrl, Shift D, it’s going to open up this debugger panel. So I’m going to say, Run in debug, I’m going to choose node j, s. And all of a sudden, I’n in, VS code and I’m to debug things here. And again, it’s not the browser dev tools, but you literally have all the same things. So this breakpoint, here, it stopped. Let’s come here, and I’m going to add a breakpoint. And it’s gonna look exactly alike. Or I’m gonna say automatic, which is odd point. And I’m gonna say, and they have different symbols VS code. So log point is, I’m gonna guess. And it’s just, it’s kind of like a sad like, mustard, yellow color. But let’s let it run. And now, I think if you’re debugging with VS code, see up top here, this toolbar is moving around. And this has got the plate but stepping to step over step out of the recycle thing. We start the debug process. So it just kind of restarts the program. So you can use those, but again, I like using the F keys. The only difference is when you’re in VS code, and you can like any change or some map to whatever, but I like the func keys for the bugging. So it’s the same thing. So like, if I press F 10, it’s going to go to the next slide, and so on. The only difference is when you press like we weren’t the browser before, you can press the play button can press a key which would continue the debugger in VS code at five. And it’s probably like, Visual Studio and Visual Studio. Not that it was at five and it still is, I believe, so that’s a subtle difference.

Nick Taylor 37:24
But anyways, I’m gonna press I’ve and to go, and you’re gonna see, I have my date and quite a bit. That’s why it’s a little busy in here. But if I open up the dev tools down here, sort of terminal, you’re gonna see I logged said YOLO. It also comes up before. And now I’m just up here. And again, access all the things that was mentioned before, so you can see all the variables here. Yeah, the debugger? I don’t know, you get used? But yeah, it’s depending on how you do it. Yeah. Like, what’s that thing again? It’s that year or, or even the button stuff, but But yeah, getting back to the side panel, I’m just gonna move this toolbar over, you’re gonna see this is kind of like what I was showing before. So it’s like the current scope, like where you are program. It shows you all the variables here. So the I, which is the counter in the loop set to zero, the count is four. This is undefined. That’s just the window. Now, there’s just nothing to find there right now. And you have your Global’s kind of like I was showing you before, a lot of these things, just Node.js stuff now. So I don’t really need to look into them. But there are things. So you can see like fetches that are for example. If you had stuff, you can put it in there, I can come here I can watch is like say like, account, it will show it. I can do other things. I can say count to you know, don’t show eight. So like you can even test out stuff, we can always use the the console too. So like in VS code, it’s called the debug console, like over here. So I can say console, log, a friends. And this is kind of like your browser Dev Tools console. Same idea. I have things all zoomed in here. So it’s a little tight for me.

Nick Taylor 39:39
But I’ll come back to the terminal. You can see that there. Now, the other thing, which is it’s in the browser and the intelligence to but there’s something called the call stack. And this is not specific to Node js or JavaScript. Just programming like this. And this is kind of you can see where things happen. Like, what got caught, what happened and stuff? Which is kind of like, I don’t know. See, we have actually, let’s add something. So I’m going to stop the debugger for a sec going to say, function hello again. And let’s just do it in. Okay, and debug this again. Okay. Now, let’s put a breakpoint in. Gonna run it. Okay, let’s get rid of that we can we don’t need this other stuff. Let’s remove point. Okay, so I’m in the now let’s come over here. And it’s like, okay, I see hello in the call stack, because that’s the current thing we’re running. And call stacks a whole other topic. Feel free to, but it’s something get familiar with the basics. Here. It Hello, got call, but this got called first. So like, it’s, it shows you It’s great here now. So it’s saying, Okay, well, what was actually called from within this loop here. And this can be super helpful when you’re trying to figure out where stuff is getting called from, like, obviously, you can structure the code and say, like, I don’t know, like, so you have some click event happens, and it calls the Hello. But like, who knows, you have like 20 buttons on different places on the page or something. So you’re not sure where it’s getting called? I’m just gonna go ahead and move your comments are, they’re still getting used to streaming. But this is super helpful, because instead of like, I’ll kind of traipse through all the code to see like, Where was Hold on, call it. If you’re if you have a recommend in the below right now, you can go oh, okay, well, I, if I click here in the stack, and you can choose other places and stuff, there’s some stuff here, which is Node.js, you can hide those things. That’s, that’s for another day, I guess. But. But this is just a faster way to know, like, what call my hello function, for example. So I find this super helpful. Now, there’s a few other things, you know, in the debugger, we can say stop on a pod exception. So I’m going to check that off. And let’s just come here. Let’s comment this out. And again, folks have questions. Don’t be shy, feel free to ask. Just gonna hide for a sec. So I’m gonna just explicitly throw in there. Okay, I’m gonna save that. And then let’s do this again. Okay, it’s gonna run out. Just remember, I’ve checked off caught exceptions. We’re gonna say, our sorry.

Nick Taylor 43:09
I gotta press. Why? Oh, my. There we go. Catch it. Oh, no, wait. Let’s do this. Let’s do try. And let’s do this. And you would never really do this in code, probably. But there’s two things. So like, let’s deal with a breakpoint first. So run in debug. And let’s run. Okay, the error got. So it’s in the catch here. But I put an explicit breakpoint. Yeah, exceptions are? Yes. Different. Yeah. This is super handy when you’re not sure what’s causing the error. So like, obviously, when you’re writing your code, you do have tried catches and stuff. But let’s, let’s run this with out the breakpoint. Now. I’m going to run it again. And I’m going to say caught acceptance. So run in debug. This should stop. Okay, yeah. So here you go. I’ve got a try catch. But because I checked off odd exceptions, it goes, Oh, I’m stopping right here. And this can be super helpful just because the program has stopped like a lot of times you’ll get the error and everything’s just and this is just pointing to the file on my computer here, but this can be super helpful. Now let’s try the uncaught exceptions. I don’t know why I didn’t catch it before but let’s let this play. Okay.

Nick Taylor 44:50
In our whole function, maybe I don’t know what maybe could have been in the top level. Maybe that’s why it wasn’t catching it. But let’s do this function you should never write but a function that, you know, throws an error, but let’s do it. Okay. So we’re gonna just again just have uncaught exceptions checked off here. And again, to be clear, I’m in VS code right now, these same options are available in the browser dev tools as well, whether you’re debugging front end code, or Node.js. And also a side note, we’re not going to today, but Deno, which is another JavaScript runtime, it’s built on V8 as well. So you can actually use the same debugging tools for detail. That’s just the side button which another runtime is a little different, I think, because it’s using things called JavaScript work from Safari, not Safari from WebKit. So I’m not sure about the monkey story there. Anyways, that’s just a little aside there. Okay. So let’s run the program. And it should stop on thought except think, okay. Maybe the demo gods with me today here. Oh, it gets close. Maybe I just happened to get explicit error. Like, like, I don’t know, see this maybe Hello. To non existent this, because clear that doesn’t exist. So let’s try that. It might be this. Okay. Let’s run it. Want to run it? Okay. Okay, I’m not sure about the exceptions. But that’s another option above her. Okay, so cool. Still in VS code. And this is super cool that we can use the debugger and stuff. It can involve a little ceremony doing that, or, or even doing what I was showing before, which was running node. Inspect, for example, VS code as a really cool feature, which is so I mean, is that safe right now for myself. This should be, you can’t see this because it’s the native context menu. But when they click the down arrow here beside the plus, in the VS code, terminal pain, there’s options, choose that sh, bash, but there’s another one called JavaScript Debug Terminal. Now, the cool thing about this one is, you don’t need to do anything to start the debugger. You just say like Node index.js. Like we’re just running it like normal. And then all of a sudden, like all that Strapping, or hurting the debugging experience is happening is because you’re using the JavaScript debugger.

Nick Taylor 47:58
Now we’re just playing, you know, index.js file. But let’s do something that might be more realistic. So let’s stop here. And I’m going to go down folder are actually do we have the package json? Yeah, this is from the React app I was working before. So we have some here I had another script here. And me just in here. Demo, doesn’t matter what’s up. Let me just close this for a sec. So folks can see. And this is just an NPM script. And I’m gonna actually just say no index.js. So save that. And let’s come back up here in my index.js, you’re gonna get rid of the error here. console dot log. Hello. Thank you, Copilot. We’ll just go with the flow world, even though I really want me to. Okay. So let’s come back to here, go back to Sage for me. And I’m just gonna run NPM run demo, which is going to run the, the flatline index.js, which is output from the console. That’s great. I come back to the JavaScript terminal. Again, like I said, I can do node index.js debugger. And I can log in, do all that. The neat thing is, the JavaScript debugger will attach the debugger. Anything that’s no so I can say I can run a demo. And then all of a sudden, I’m running an NPM script. don’t have set up the debugger or anything. I’m just all of a sudden, like, the magic sauce in VS code said, Okay, well, we know you want to use the debugger. So anytime some kind of no GS processes running, we’re going to attach your and this is typically how to Node.js logging VS code. I almost always use VS code for debugging and Node.js. I think the only time I would probably use the browser tools these days is maybe I was in a log cabin without my normal setup only had like Notepad dot exe and the browser preview, but, but it’s pretty rich. And this is VS code. I’m a fan of it. It’s free open source. But like if you’re using something like WebStorm, like I said, built in no GS debugging capabilities, but I’m not sure if they have concept of the JavaScript debugger. For folks that use WebStorm, you are aware on the competence for drop a message later. Cool. Cool. All right. We’ve got about nine minutes left. Okay. Question from? Mark. I don’t know. But I think what happens is their monitor processes that are running and if they see a node process runs, because like you can have, like if you’re running a build, or something, multiple node processes, startup, pretty sure the job terminal just goes like, you know, the debugger to each one’s how it does that? Positive but probably like, some abstraction layer. When running the JavaScript, you’ve got to remember to do that. Yeah, no, we like to be on there and stuff. That’s all good. It’s great question. I like to know exactly how. Okay, so yeah, eight minutes.

Nick Taylor 52:14
So we’ve been showing how you can debug is in VS code here. Now. The other thing I want to show you is, as you can see here, this is the running debug panel. So that’s this URL here. It’s this bug with like a, again, you can act by Shift X, if you’re on Mac. If you’re on Linux, it’s Ctrl. Shift X. Again, though, if you keyboard mappings that might not be that but, um, so we have all these enable to debug, and also say, create a launch file. And I’m going to pick up GS here and just close a bunch of stuff here, because Okay, so this is something that VS code offers, and you can have just different configurations. So here, this one just allows you to specify like, okay, index.gs. There’s special variables in here, like workspace folder, it’s like, my current project. So this is one way to do it. There’s some interesting things here. Well, you can decide to skip files. So for example, say you’re, I’m not going to run this now. But basically, it’s going to start the debugger again, it’s just a way to start it. The way we’re doing it is not the JavaScript terminal. But the way we’re checking the debugger. Yes, code besides on sensible defaults, which I believe is pretty much this. But this is interesting, because you could say, like, here are things LGs goals, because depending on what you’re debugging, you might end up into weird stuff, no GS itself. But say you’re like, a library like I don’t know, like CEOs. And you’re talking. I don’t really use Axios. I use Fetch generally, but whatever. Axios. He’s like, somebody stepping minimalist, in this, like Node modules killed for this particular library. It’s not something you really care about. You don’t want to go in there. That’s not helping your debugging experience. So you can just add that you can say like, modules, skip all you can say, skip a specific one.

Nick Taylor 54:46
And there’s, so you can browse. I mean, cool. I’ll just show that real. Oh, my time check. We got five minutes. Okay. Let’s go into browser debug. tools here with I’m just going to act here for a sec. So I can actually see everything. Give me one sec. I’ll be back in a second, I just got to find the spot. Ignore list. There we go. Of course, it’s not, okay. Don’t stress and ignore this. So if you’re in debug tools and not in the co2, so like, say you don’t want it stepping into like framework code, like React or something, can basically create large questions to say, like, I want to be able to, like code, but like, I don’t care about, like some of these libraries who like, it’s not important in debugging experience. So you can also just add things here, like, you know, people were using jQuery, they use this, you know, and just added, because they care about snipping in that. So there’s that. So I just wanted to show that contrasting it to like in VS code here. The other thing here is, it’s out of, kind of out of scope of what we’re talking about today. But you can have different configurations. So you can attach to Chrome, which is kind of nice. So like, you can say, say we refresh our app, I can just attach to Chrome immediately. Which means like, even though I didn’t have like being set up, if I open up the Dev Tools, and then I run attached to Chrome, all of a sudden you can debugging your browser code within vs. Code. That’s, that’s another thing. And again, it’s it’s the same experience with the dev tooling. If you’re a fan of VS code, or I’m pretty sure WebStorm does this too. You can just it’s just a different experience. Right? Yeah. My dream still is to kind of have VS code and then dev tools as the browser, but maybe that’ll happen one day. Anyways, we got a few minutes left here. So just see if there’s any other questions before we kind of wrap it up here. And I just wanted to mention, too, so you can attach to other browsers. And you can also attach it directly. There’s many ways but going back to what I was saying before, I typically is the JavaScript debug, typically these days, but there’s all kinds of things in here. And if you have other jobs in stock, like for example, Russ, you know, even charge us this debugging experience. It’s just different for that particular language. Yeah, that’s true. A lot of the same tools. So just kind of wanting to match that there. Let’s see what else. Yeah, so there’s that. And the thing is, save this file, hit topic for the next episode? That’s a good question. I didn’t discuss it with Brian. Yeah. But I was thinking maybe, you know, because the whole point of we’re kind of what we discussed is, I like the full two stack, but it’s kind of touching on web topics that people might not have covered. And I know you’re a fan of Ross up first. And you know, like that the frameworks and stuff, I was thinking of doing a deep dive for the next stream into forms. You know, like, there’s a lot of reforms, little teaser for folks. You know, like people who’ve been doing react, for example, there’s like, warm, light or used to like, let me get the state of what’s in the form and stuff. But there’s, there’s already API’s that do all this for you, for example, like there’s a form data class, there’s .vim property available on elements that are in a form. There’s, I don’t wanna give way too much. But I’ll give a chat with Brian, but I think that might be the next episode. And the other thing is, I’m glad Yeah, questions the fan, because folks in the chat, or even watching this recording later, if there’s things you’d like me to live quarter discussed, you know, happy to do this. But yeah, now this has been super great. Just want to give a quick shout out to Brian and the CFE.dev team for starting and I’m really excited about this collaboration. So I hope folks enjoy today as a little peek is my first time with stream yard. Brian and tightening that up a bit. And yeah, can fall into CFE.dev already. For myself, like I said, I’ll just drop my links again. They’re just there. But you can give me a follow on all my socials if you’d like it Appreciate it. Extreme on Twitch if you want to follow over there, you can check out my website developer doc. There’s all my links, blogging, street, socials. And yeah, that’s pretty much it. Two o’clock on the dot. Thanks for hanging out and see you in the next one.