When writing a Vue application, debugging is a very effective tool for figuring out the cause of a problem. Steve talks with Cecelia Martinez about her recent talk at Vue Conf about all of the various tools that are available to help debug javascript applications and some Vue-specific options.

Hello everybody and welcome to yet another episode of Views in Views on View, not in view views on view. I am Steve Edwards, the host with the face for radio and the voice for being a mime, but I'm still your host. Today we get to talk about debugging in view, one of my favorite topics that you know if you've listened to this before. And my very special guest is Cecilia Martinez. How are you doing Cecilia?

 

Hello, happy to be here.

 

Right, so Cecilia came to our attention of our hardcore recruiting crew when we saw a presentation that she had done on debugging in Vue. I think it was at VueConf, if I remember correctly. We have the link, you can see it on YouTube or Vue Mastery. And so I said, let's get somebody to talk all about debugging. So before we go down that road, Cecilia, why don't you give us a little intro, tell us who you are, why you're famous, other than this maybe. your developer story, et cetera, et cetera.

 

Yeah, absolutely. So I'm Cecilia Martinez. I am currently a developer advocate at Ionic. It is a framework essentially for building hybrid mobile applications. But I have previously worked at different open source developer tools. That tends to be my passion. I've been at companies like Cypress, which is for software testing and replay, which is a debugging tool. I like to also kind of do various volunteer work in the community. I am volunteer with Women Who Code front end. And I'm also the chapter head for the Atlanta chapter of Out in Tech, which supports the LGBTQI plus community in tech. And yeah, you can find me doing various conference talks or webinars or writing blog posts, I love teaching, and I love digging into making the developer experience better and more accessible to as many people as possible.

 

As a developer, we like your kind of people. They make my job easier, make our jobs easier for sure. For sure. So before we started recording, you were giving me some background on all of the, I think you said something like 10 talks on debugging in the past year or something like that. So, and that you mentioned you don't just do Vue, you do other frameworks, other tools, other languages and so on. So tell me what you were telling me earlier about. just the toxin and all the things that you deal with or help with debugging.

 

Yeah. So I essentially, I guess I started using a tool called Replay back in December of last year, it kind of first came on my radar and it is a time travel debugger, which means that you can record your application execution and then play it back to debug it. It can be, it's records in the browser or a node. So you can kind of use it for various types of JavaScript based applications. And once I kind of got started with that and going down that rabbit hole, I really went deep into debugging as a process and all the tools that are available for debugging, and ended up doing 10 talks this year on different types of debugging. Debugging Angular, React, Vue, definitely, but also just the process of debugging and why it has become so much more complex. One of the things that I talk about and from talking to other developers have realized is that nobody really teaches you how to debug. No one sits you down and says, All right, this is what happens when you find a problem. This is how you approach it. These are how you use all the tools. This is what a break point is and why you'd want to do it. Um, it really ends up just becoming a lot of trial and error and it becomes a really frustrating process and people hate it. Like that's one of the big things is like you spend half your time debugging, but nobody likes to do it and nobody really knows how to do it very well. And so I wanted to figure out why that was and how we can make it better. And so. I talked to lots of developers and started digging into these different types of tools and found some common patterns and kind of turned that into the talks that I've been doing throughout the course of the year. So that's how I started getting involved with this topic of debugging.

 

Yeah, it's you know speaking from from my perspective debugging is Probably ever since I first started writing PHP I learned how to debug how to figure out tool like and it was actually somebody that pointed me in the right direction There was back in what early 2000 before I think before jet brains before PHP storm There was another well-known PHP IDE and it starts with an M and for the life of me. I cannot remember what it was called but the guy Matt, who was the founder of a really well-known Drupal shop, Lullabot, said, hey, I've checked out xdebug in this IDE. And I was like, oh, so I started digging into the docs and got it figured out. And once I got it configured and could set my breakpoints and run my code and hit it, I was like, oh, this is a lifesaver. Not only because, you know, setting a breakpoint and running through code is one of the debugging tools, obviously. but you can once see, watch it step through and see, oh man, I'm missing this loop or I'm jumping out of this loop because this isn't set. Or you can hit your break point and then look and see, okay, my variable is this value at this point. No wonder this isn't working and stuff. So the step debugging is just immense, immense. It's with PHP and it's a little easier on the backend than it is in the front. And the browser tool debugging can be a little sketchy at times, but. there's still a lot you can do with step debugging even in your standard dev tools. Setting breakpoints and editing in them and viewing variables at certain times and stuff like that to the point where, I just hired two developers for our company at GovTribe. And one of the first things I do when we get them up and running is, let's set up xdebug in phpStorm, which is our IDE of choice. This is how you can use the debug tools in the browser to help figure things out and they use it. That has helped me over the years. That has helped me so much to be able to debug things and to fix things. When I was at a few years ago, I was working at a really huge application. We had a corporation and we had a pretty large dev team, probably, well, for me, 10 to 20 people. They saw. how I could figure things out so easily with a debugger that they asked me to teach a class to all of the other developers because it was such a tool that really helped them to stop and see things, you know, instead of having to do in, you know, in Laravel, you can do a DED and dump it out. Okay, great, but what happened before

 

We have.

 

that? How did you get to that point in the first place? So anyway, that's my little rant.

 

That's amazing. So like I just complained that nobody really teaches you how to debug, but you're actually doing that. You're going and you're teaching people how to debug when they come on. And that is a huge benefit to not only them, but the entire team, right? Because you end up having a better shared vocabulary for how you approach

 

Mm-hmm.

 

problems and being able to go through that process. And that was something that I did find. when I, so I started by talking to developers that were using the replay debugging platform and I would have on a call with them and them and just be like, let me watch you deep up, like, how do you do it? Like, let me see, let me see the magic happening and, um, no.

 

Oops, wrong button there, sorry. That wasn't a joke. I just hit the wrong button.

 

So do you want me to start from that kind of beginning, a sentence? I think.

 

Or we can leave that in either way.

 

Okay.

 

I think it's sort of funny myself. Sorry, I didn't

 

Yeah.

 

mean

 

No worries.

 

to. We'll edit this little part out, but yeah, just go ahead and keep going.

 

Yeah, so I sat down and I wanted to see like the magic happening. I was like, let me watch you debug. And, um, I, I saw, I started to see a couple of patterns. One was definitely understanding how to use the tools, right? Knowing how to step through what that meant, understanding the flow of your application code. And I think that's something that gets lost a little bit with abstractions. So one of the, another theme that kind of came up is when you start to leverage frameworks, especially for front end development, um, It adds complexity to our applications because you're not only debugging the actual application code itself that's running in the browser, but the interactions between whatever tools or frameworks or packages that you may be using and what actually ends up running. So that's something where we see the framework dev tools, like Udev tools, for example, comes in handy because it shows you how your components are rendering and lets you inspect your component state and props at different, you know, as your application is executing. So that's something else that I definitely have seen

 

Yes.

 

is from talking

 

That's

 

to

 

my

 

some

 

opinion

 

developers.

 

on the view dev tools by the way.

 

Yes,

 

Okay

 

yeah.

 

crowd, you can stop tearing now.

 

I was very impressed with Vue DevTools. I have taken a look at Angular DevTools, React DevTools. Vue DevTools has that really amazing profiler, which shows how all your components are rendering. And Vue also has some built-in methods that let you log and trigger, log what's triggering renders as well, which isn't built into some other frameworks. And that is really helpful when you're... trying to understand why something is or is not rendering, and then also debugging performance issues that can come with too many renders.

 

Before we go down there, I want to go back and talk about Replay because that looks really interesting. So how does that platform work? How do you integrate that into your, say, a Vue application?

 

Yeah, so Replay at its core is a runtime recorder. So it works in the browser. It also works for Node. Replay itself is a browser. It's a fork of Gecko Dev or Firefox. It started at Mozilla with the founder, and it came from Mozilla with the Firefox DevTools team. And it's a browser, and you essentially just hit Record. You run through a flow of your application. You recreate the bug, so to speak. And from that, it creates a replayable recording of what just happened with DevTools built in. So it runs in a browser. The DevTools platform is actually open source and you can see it there. It's free for developers to use. But you record your bug and you can replay it over and over and over again without having to reproduce it every time. And you can inspect the application, the DOM, the elements, the HTML and CSS. the framework components, and then also all the JavaScript that's running in the browser at different points in time. So you can pause, rewind, fast forward, and inspect values, components, variables, props, state. And you can even add console logs retroactively, which is my favorite part. So if I thought,

 

Dang.

 

wow, I really wish I had a console log there, you can actually just hit a little plus button in that line of code, add the variable that you'd like to output. and it'll show you the value every single time that that line of code executed during the recording.

 

So is it like a video replay where you're watching it on your screen navigate through everything?

 

Yeah, so there's a viewer mode that will show the DOM. So it's actually, it's not a video. It's actually, we're literally repainting the canvas. It's like,

 

Okay, right, but it's a visual replay of your page, right?

 

exactly a visual replay of the page. And then there's also a backend view or a dev tools view, which shows also the JavaScript execution that's taking place. And it looks like browser dev tools. You have your react components that are there and you can inspect and it has a timeline on the bottom to let you scrub through.

 

I am so trying this out.

 

Yeah, I first came across it and I was really thinking about whenever I would try to debug, I think engineers have this mindset that we want to understand how things work, right? And we want to dig into it. It's not just satisfied of like, okay, it's working. We want to understand why it's working. And for some reason, I think because I didn't necessarily know the best way to use debugging tools that seemed to go out the window whenever I ran into a bug that I wasn't sure how to approach. And so... I was kind of, I started, I have this, this joke in my talk where I have the debugging dart board and it has just like all the random things that you try, you know, commenting outlines, adding a bunch of console logs in random places. And, um, and so, and that's some kind of what the approach that I used to take. And that's why I found it so frustrating. Um, so when I was able to really get dig in and figure out how to use tools better and be more intentional about debugging is when I started to kind of see how it could be fun, like it's a puzzle and not just a frustrating one.

 

I know for me for debugging as a process, I totally get the dartboard. I haven't seen it, but as you describe it, I can totally imagine that. What I've sort of figured out over the years is to start at the point where the failure is and work your way backwards or up the stream as the case may be. With one of my news guys started like first week we were working on something and he was trying to figure it out and he's flailing all over the place. I've tried this and this. I said, okay, here's your data missing. Where should it come from here? Okay, this should be coming from here. And it turned out in this case, it was a missing prop being passed into a component, into a child component from a parent component. But, you know, when you start getting flustered and oh man, this doesn't work, I'm gonna go try a DD here, I'm gonna do a console log, or I'm gonna pre-out a, you know, whatever, start from the one point and work your way backwards, generally tends to be, you know, the way to do it, just from a, you know, high level overview type of approach. But yeah, I can sympathize with the dartboard.

 

Yeah, definitely. And that's kind of what I started to find too, is one of the things I would do during my talks is I'd ask people in the audience, like raise your hand and what's the first thing you do when you encounter a bug? And some of them would start saying things like, you know, like add a console log and they start reaching for tools, like for solutions. But really the first thing that you do is, you try to define what's wrong, right? Like what is actually wrong? What is the problem we're trying to solve? And in order to know what's wrong, you have to know what right looks like. And so that's where, uh, sometimes it can be difficult because sometimes we don't really know exactly what our applications are actually doing. We have an idea of what they're supposed to do, but when they break, it's a understanding what is really supposed to be happening here. What is the flow of that execution? What is the flow of the data? You know, where are the props? Like you mentioned in your, in your example going through. And it's a little bit of a challenge sometimes to be like, do I really understand what it's supposed to be doing in the first place before I dig in and try and figure out what's wrong? And so, yeah, defining the problem and then isolating it, like you said, and tracing it back to the root cause is a process that I saw appear over and over and over again as I was watching people debug.

 

What you know the old adage is that computers do what you tell them to do, not what you want them to do. So yeah,

 

Yep.

 

I think that's definitely true.

 

Absolutely. Yeah. And so with the frameworks, like I said, too, once you add abstractions on top of it, I love working with frameworks. I think it makes it really accessible to get started with developing. And you get to that magic moment a little faster, where you're like, oh, it's on the page. It's working. I'm clicking around. But again, when you get to the point where you have a lot of abstractions and then something breaks, if you don't know what's happening under the hood, that's where it can get more complex to have to debug. And so, well, what

 

Well,

 

I

 

that's

 

found actually, yeah.

 

true for anything. Sorry.

 

Oh, sure.

 

That's

 

Yeah,

 

true

 

yeah,

 

for

 

no, go

 

anything

 

ahead.

 

is knowing your tool. I can think of, this is an example that goes way back to before I even got into computers when I worked at a bank. And I can remember hearing, and it wasn't so much true by the time I started working at a bank as an operations manager, but even before then where they hired a new teller, they would just have you start counting cash. Just tons of cash, tons of cash, right? You get used to know what it really like and then they throw in a counterfeit. And because you know the original so well, you can spot the counterfeit, right?

 

Mm-hmm.

 

So in the case of Vue, which is what our podcast is about, if you know Vue and how it's supposed to operate and how your application is supposed to operate, then when something's not right, it helps you better to identify, oh, it's right here. Oh, it's just because at this point it's... doing this and that can be really frustrating if you you're new to an application and you're trying to figure out a bug but you don't know how it's supposed to operate yet so that's where you know just the time and and and of working on something that gives you that familiarity but but I think it's more important to you know and this goes back to my days in tech support doing communications between PCs and mainframe systems with screen scraping those were the days

 

Thanks for

 

where

 

watching!

 

you know if you know your tool when a customer says, hey, this is wrong, you can say, oh yeah, I bet you that's right here. You know, that

 

Yeah.

 

type of thing, so.

 

So it's so two things, actually, funny enough. I also used to be a bank teller and I also use Sercan tech support. So maybe that's why I ended up in this, in this space where I like trying to solve difficult things, but yeah, I think one of the talks that I saw earlier this year, it was at reactathon, but it was debugging Java, async JavaScript by Jen Creighton. Her tag is girl code G URL CODE on Twitter, but she has this. like this thesis where it's like, you don't know something until you know it. Right. And I've found that I tend to learn so much more about whatever tool or my application or my code base, uh, when something goes wrong. So if I'm on the happy path and I'm just following the docs and everything is working, it's like, okay, I'm just at that point, I'm really just following instructions, but when something goes wrong. That's when I have to dig into that. Okay, what does this, I'm going to go to the actual API command docs and figure out what all the different parameters are. Okay. Now I have to do this. Now I have to read all these error messages. And that's where you really, um, I have found that I learned a lot more. Was having to debug it when something goes wrong versus just that happy path. And same thing with, um, when I was at Cypress with test code, right? If you write your test code only for that happy path, it's probably going to pass, you know, every single time. But then when your actual users start to use the application and they're doing things that you don't expect, that's when it breaks and that's when you start to learn. Oh, I guess my application will do that. If it, if I input a special character in this form, or if, if I hit the back button 10 times, or if somebody tries to upload a file that we don't accept. And so getting off that happy path and breaking things is where you tend to. It's a really start to learn and start to know things. that will help you better understand your application going forward, so that you know what to reach for the next time something happens.

 

Yeah, again, that's the same. I mean that's the same in any aspect of life, you know When do you learn most when everything went well or when it failed right because you? Learned how to respond how to adjust you know how to How to address the problem and maybe what not to do the next time you know you come

 

Yeah.

 

to that

 

And that's something I really try to emphasize. Like I do some mentoring with people who are early career, um, or getting, or trying to get into developing and they feel like when they messed up or they did something wrong, that it means that they, that they're not good at it or that they, and I'm like, no, this is the great, this is the great part. This is the, everybody goes through this. You know, I talked to developers who've been at it for decades and they have those moments where they're just like, what am I doing? Why is this not working? And, um, that's something I really try to emphasize is that. this is all just part of the process and you know, learning and failing and learning go hand in hand. So.

 

Cool. Alright, so let's start to get into some of the nitty-gritty of some of the methods and or tools that you use when you're debugging a view application.

 

Yes, absolutely. So one of the first ones you talked about is having that good process. But I am a really big fan of Vue DevTools because I think it's really well done, but it's also something that gives you access into what's going on under the hood in your application. So if you've never used Vue DevTools before, it's pretty easy to get installed into your browser. And then whenever you have a Vue application, where you have your components, usually in dev mode, you're able to access that and inspect them. So there's really a couple of aspects of that. There is the inspect kind of functionality where you're able to actually view your components and you're able to view your components, the props and the state. The thing is, it's gonna show you what your props, your state, your setup, everything that's declared within your setup function review. But it's going to have to be for a certain point in time. So if you open up your application, you have the DevTools open, and you start to click around, you're going to see that update on the right-hand side within the DevTools. But it's really helpful because it does let you see, for example, if you're expecting a certain value in your setup to update when you interact with an element and it doesn't, you can see when that happens. The other aspect of it is, of course, the timeline. which is more around what Vue is doing with your code. So Inspector, you can kind of think of it as in this given point in time, what is the value of everything in my application? And that can be super helpful if you know where to look and you need to essentially see things across different points in time. The nice thing is if

 

So.

 

you record it with the time travel debugger, then you can jump back and forth without having to recreate it every time. But...

 

All right, so that seems like, so that's sort of a replay type of thing in that you can go back in time without having to actually step through your code again and again to see what it's doing, right? It's sort of a recorded thing and then you can just replay it as you wish.

 

Exactly. So you can reproduce the bug once and you can record the bug once and then it's reproducible forever. So what you'll see is if you have a new application open with the inspector in your Vue DevTools, as you type, for example, in an input, if you have that connected to a reactive or a ref in your setup function, you'll see the value in DevTools updating as you type, if you have that set with a V-link in order to keep those in sync. But if you have had a bug occur and you know what happened initially, you can see that update at each point in time by rewinding it and replaying it. So that can be really helpful to understand, is your state updating as you expect it? Is a prop from a different component actually still showing up in that child component as expected? Are your events being emitted back up? You know your component tree as expected. That's a big one. I have definitely forgotten to emit an event to call the event handler function. And so that's something that can be really helpful as specifically with the Vue DevTools. And then I mentioned the timeline earlier. This is something where it'll show how Vue is actually rendering your application and... which components are firing off and which components are being triggered. And that is a little bit more helpful when your application is not behaving in the way that you expect it based on how you're using the framework. Right? So that is something that's a little bit different. I talk about when you click on a button in your application, it could be the... There's so many steps that could take place. Like an add to cart button, right? It could be your API requests going out. It could be the response body coming back. It could be that it's reading a microservice and that didn't work correctly or it was down at the time, or it could be that you dispatched to your state wrong and not so many things that are taking place, but if it's something where all your business logic is correct and it's just, you're not sure if you is perhaps handling something in a way that you don't expect that's where the timeline can come in really handy. because it's going to show how everything is being rendered. And that's also where the component debugging hooks are going to come in handy. So there are two component debugging hooks that I've used. There probably are some more, but there's onRenderTrigger and onRenderTracked that you can essentially insert into your code. And then whenever a render is triggered, you can execute some kind of like function, callback function. Typically you can log the event, that's a good one. You can also just put debugger in there and it'll pause at that point in your execution so that you can inspect the event and then that will actually show you what is causing that trigger to render or what is causing that render to trigger, which can be really, really helpful if you're not sure why something is triggering. So view is the only one I've seen that has like. that easily documents and they're really easy to find, these debugging hooks. And so that was really, really powerful when I had a bug where I have a bunch of cards on a screen with a little, and you could vote on them, plus and minus, it was kind of, and I would click on the plus button on one card, but all of my cards on the page re-rendered. And we don't really want that because I'm only able to be interacting with one card on my page and I don't need everything to re-render. that can become very performant, like, you know, not performant. And I was able to add that hook and I was able to see the, the target. And I was able to see what triggered it and the value of it and what actual like value in my setup function was causing that to re-render. And I was using a, or an array that wasn't deeply nested because I was using a reference instead of a reactive or with view of view three and so.

 

Uh huh.

 

I was able to figure out what was going on there and update it so it was more performant.

 

You mentioned in the DevTools putting in the debugger line, you know, to automatically stop right there. I've discovered over the past couple years that sometimes, you know, we're still on slightly older Vue 2 app that uses Webpack. And in the past I've always had good luck where I could open other DevTools and do like Command-P on the Mac, put in my file name and, you know, open up the file that I wanted. But as with the latest four and even five there have been some serious source map issues where it's not quite so simple anymore, where I'll go to open my dev tools and there's five versions of the same component and some are completely

 

Thank you.

 

rendered and some are the original source code. But the easiest way I figured out how to get the correct one open in the browser tool so that I can put other breakpoints is just throw a debugger line in there somewhere and then it'll stop, opens it up, okay, there it is right there and now I can put in my other breakpoints and it works. But Webpack has... least in the latest versions has caused some headaches,

 

Yeah.

 

at least in in Chrome. I haven't really tried web debugging with beat yet. I've got an application, an inertia application I'm going to be working on soon so I'll have a better chance to to see how it works there but I'm hoping knock on wood that I can still do my browser tools debugging with beat.

 

Yeah, yeah, one of the things that I learned along the way is in browser tools, basically hiding out the function executions that happen in certain folders. So, you know, it would trigger something in a package and I would see all those functions start to pop up and step through those. And I was like, I don't really want to step through those. I just want to step through the code that I wrote because

 

Right.

 

my code is probably the one that's wrong. And

 

Uh

 

so

 

huh.

 

somebody showed me how to disable that. So you can essentially take out folders that you don't want to trigger certain packages. in DevTools. And then Replay will actually let you ship source maps too. So if they're not published publicly, you can ship them to Replay's API and it'll match them up as well. Debugging minimized code is a special talent that I personally cannot do. Some people on the team can. But I think they're just so used to looking at it. But yeah, so having those source maps with the real components and seeing all of that is a much smoother process. It's also interesting to see where people like to debug. Like I like to debug in the browser. Some

 

Mm-hmm.

 

people really like to debug in their IDE. Um, so it's kind of like, obviously the tools change depending on what and like environment or platform that you're using. And so I've become like really like browser dev tools for me, because that's going to be this similar, as close to the experience of the user as possible versus the developer experience, which is what's happening in the IDE. So. Kind of two sides of a coin there, but it's been interesting to see.

 

Yeah, I'm the same way. I tend to stick with the browser debugging tools. I know I've done it before. It's been a while. I played around with VS code and one of their debug configurations where I was actually able to debug in the IDE, which I think is really cool. And maybe I'll try to play with it again at some point. I know I think you can do it in PHPStorm, but I haven't really tried. But for the most part, I'm just so familiar with the browser tools anyway and being able to debug in there that I just stick with that. If anything broke, don't fix it, I guess.

 

Yeah, I think people who are maybe come from backend or are more used to not having something that's rendered, maybe move more comfortable in the IDE. So I've kind of seen that before too. Replay has a node recorder, which some people have used to debug TypeScript issues, just kind of recording their node executions of that compilation process. And that doesn't really have anything to look at. It just has the code execution. So I could see how that could be maybe more comfortable in the IDE.

 

Right. So I don't know if you were going to go down this road, but it's some of the things that I don't think people realize you can do with debugging in the browser. And you can do this with X debug. I know, you know, with PHP back and not sure about node is how you can configure even your breakpoints. You know, usually you'll click on a breakpoint and OK, it stops there. But you can do things like say, OK, only hit this breakpoint if a specific value is true at this time or if. if it's coming from a previous breakpoint or you know something like if this one's been triggered first. So a common example I've done this before is where you're trying to see what is getting passed to your back end in an HTTP call. You know whether it's a you know fetch or Axios or whatever and so you've got some wrapper function but it gets called that's it's a common function so it gets called everywhere and you don't want it to hit every time it comes in in this method. So you can set a previous breakpoint and say Okay, if it hits this one, now trigger this breakpoint so it only triggers the time you need it. And there's all kinds of other configuration options. You usually just have to right click on it and edit, and then you'll see all kinds of different things that give you more control over when that breakpoint is actually hit.

 

Yeah, conditional use of the tools is really helpful. So there's conditional breakpoints. So within, I mentioned earlier within replay that you can add console logs retroactively.

 

Mm-hmm.

 

You can also do conditional logs. So you can say, like, you know, so for example, if I had a bug where something was resizing and like the width of the object changed over and over and over and over again, but I really only cared once it got close to zero. So I was like, you know, if this value is less than four, then log it. because I don't really care about all the other times. And so that really helps going back to, we're talking about the process of isolation. So being able to narrow your focus into just where you think the bug is and being able to kind of get the noise out can be really helpful. And so that's a really good point. The conditional breakpoints, conditional logging, we kind of talked about too, like removing the folders that it uses as for the sources of stepping through, all that can really help you isolate in.

 

Well, you know,

 

us.

 

you talk about console logs and, you know, using the console tab within your DevTools. I have a great article, bookmarked, I think it's on my other computer, that talks about all the different variations of things you can log in your console. So console log obviously is the most commonly used. It says here, give me this, at such and such point. But you can do things like console trace, I think, which gives you a

 

Yeah.

 

stack trace. You can, oh, console error, I think is one. So it highlights an error in red. If you do that, I mean, it's amazing the things you can do just with console logging that that really help you highlight what's actually going on, you know, in your in your browser and in your code.

 

I did see a tweet recently and this kind of blew my mind, but somebody was like, I have a bug and for some reason adding a console log fixes it. So they had a

 

I've

 

console

 

had that.

 

log

 

I've had that.

 

because what they were doing is they were logging the output of a function and it was calling the function, which was resetting the state, and then it fixed it. And so adding the console log. It was, they were like, what is happening? Why is this happening? And I followed the thread because I had to, I was just so curious and it had to do with logging, they were logging the output of a function, but in turn, they were actually calling the function and it triggered something in the code that then was like, okay, now it's working. Whenever they removed it, the bug came back. So.

 

I think I've seen that before where it did it because calling the console log caused a pause or caused it to slow down just enough that something else could happen. Because you're like, dang

 

Wrist

 

console

 

conditions.

 

log, it works and no console log and it doesn't. Really? You know, so that's sort of a clue too.

 

Yeah. Yeah. Race conditions. Um, yeah, I can definitely sometimes like Cypress, you know, debugging Cypress issues, automated tests are so fast. Right. And so sometimes just waiting a couple seconds would cause it to, to work, you know, um, so people kind of, we get stuck on that, they'd be like, Oh, just add a couple of pauses in, or I'll add a couple of weights in and it's like, no, you should, we should figure out why, like what's happening in that two seconds. You know, like that's a. Let's dig in a little bit and see. But

 

Yeah, we run

 

this

 

into

 

is kind

 

that

 

of...

 

in dusk tests. So we're using Laravel when you use dusk, which is a front end testing framework. It's like, it's a Cypress, I think, just built in Laravel.

 

Mm-hmm.

 

And we try to avoid that too, because one of the available methods in dusk is pause. But what you really want to do is use some of the methods like when available or

 

Yes.

 

when this is true or when this is true. So it waits, okay, now this is true. Now check and see because it should be there by then. And we'll go back to our dusk. you know, if you do a quick search on pause, you'll see, oh, there's about 10 or 20 in there. Well, we should probably get rid of those, you

 

Yeah.

 

know, at some point. But yeah, just throwing a pause in there, I think can actually be masking, either masking or it's just sort of confusing, you know, as to what are you waiting for, where if you use a when available or when this is true or wait for something like that, then it's a little more clear as to what you're looking for in your test.

 

Yeah, makes it more deterministic. Um, it also makes it easier to understand for the next person too, because then they, they know, oh, okay, it's because we need the API call to come back or it's because we're waiting for the data to actually like render on the page and before we assert that it's there and, uh, yeah, we kind of call that the Heisenbug at replay is basically where the bug changes just because you've observed it or

 

Right.

 

observe observing

 

The quantum

 

the bug

 

theory

 

changes.

 

of debugging.

 

Yeah, exactly. It changes the nature of it. Um, and so. We've had things that only reproduce under very specific conditions and you don't know what they are. And they always say, if you can't reproduce it, it doesn't exist. Right. It's kind of

 

Right.

 

the old adage. A lot of closed GitHub issues because there's no reproduction and

 

Mm-hmm.

 

things like that. So that was something that we've seen every once in a while, those goofy bugs that justify the laws of physics somehow.

 

Mm-hmm. So we've got dev tools, we talked about console logging, you've got your break points, you got your stack trace. Did we cover everything the dev tools can do? I know that with the latest version, I don't think I've used all of them, but I use the Vue X and the components. I know one of

 

Yeah.

 

the things I like to do with the Vue dev tools, and I think you mentioned this, is in the components you can go through... the hierarchy of all your different components on your page. I know in our app, I was just before I came in, I was trying to resolve an issue that had got to have 15, 20 layers of components and some are using slots and some are not and so on. But the nice thing is you can filter and say, okay, find this component, okay, it finds it for you and then when you click on it, you can see, okay, in the loaded state, here's all the data that it has, whether it's a prop that's been passed in, whether it's defined in the data object, coming from Vuex or some sort of state management. You know, what's there? And then you can see, oh, no wonder I'm getting this error because I'm trying to read something on undefined. Well, it's undefined because this isn't here, you know, type of thing. So, in addition to time traveling, just seeing what's there can sort of give you a starting point to say, okay, if it's not here at this point, then something up the stream is not. doing his job or data's not getting passed down like it should be or something like that.

 

Yeah. And speaking of that aspect of it with Vuex, something I didn't know until more recently this year is that Redux DevTools, which is used to debug Redux and it has a time travel capability where it'll show you a timeline of all your dispatches, also works with NGRX and Vuex. So anything that kind of has the same format as Redux, you can use Redux DevTools. So you can actually use Redux DevTools on Vuex as well to see a timeline of all of your dispatches and a diff. in the state every time one occurs. So that's something that you can add if you want some additional kind of debugging functionality specifically for your state, which can be really helpful.

 

So does the redux, I mean, I'm not sure if it's heresy to consider mixing React tools with Vue,

 

Thank you.

 

but does the React DevTools from the Vuex standpoint provide some functionality or features that the Vue DevTools don't?

 

So this is, so there's React DevTools, this is specifically Redux DevTools.

 

Okay, ReduxTabTools.

 

And so, yeah, so it's just, it's a separate tool and it's really just handles that, all like the different actions, like the effects and the, or when you're in that kind of, oh, is it flux? There's like a certain pattern of that style of state machine, essentially. And it's just designed really for debugging that. And it shows you the timeline, and it shows you a diff chart. And it kind of creates some nice different graphical views to show you

 

No.

 

how your state is diffing across time for at each step. So if you have a very complex state machine, I'm sure it becomes a lot more useful. Most of the things that I've worked with in Vuex haven't been that complex. It's more just kind of pretty straightforward. But I have seen some pretty cool things done with it. So it may be worthwhile if you are working with a really complex state bug.

 

Mm-hmm. So any other tools, methods or anything that we're missing that you use for debugging,

 

Um,

 

maybe some fringe stuff?

 

yeah, so kind of a more, um, fringe thing, as I mentioned too, is earlier is like what happens if something is wrong with, like it goes wrong with the, within the framework itself, right? So

 

Ah yes.

 

not just how we're using the framework, but I bug in view or a bug in, you know, in TypeScript or in react. And so one of the things that I discovered is that when you record and replay in the browser, it records everything that happens in the browser. if you're in dev mode, right, including the render process of all the functions that are being called by view, by the framework. So you can go in and you can see, for example, create HTML element is a method within view. And you can see it being called every single time, rendering these HTML, creating these HTML elements that are being rendered to the DOM. And so if you have a suspicion or you don't understand necessarily how something is happening under the hood even further, you can actually record and then debug the view code itself. Really the only other way I know to do that would be to go into like the node modules, like, you know, view package and

 

Ugh.

 

try to add breakpoints or logs there. So that becomes really like more handy, like a handy way to do it. And somebody, his name is Matush Brzezinski, he's Andorist right on Twitter, but he found a bug inside of TypeScript. using a replay node. So you notice it was with a union type, a generic, yeah, something where he recorded it and you were able to, again, you're recording the actual TypeScript execution of TypeScript compiling down to the JavaScript and they were to find that there was a certain method that was being called, but only for... method and named functions, but not for arrow functions, or some kind of combination of that, where two out of the three different function types were accounted for, but not the third. And

 

Uh huh.

 

so that was causing an inconsistent result for the typing. And again, the only other way to do that would be to go to dig into the TypeScript code and start to like try and add logs or break points there. And so if you need to dig even deeper into those layers, that can be a way to do it is recording the actual execution and with something like replay or a different time travel debugger.

 

Now have you, you talked about going into, you know, your library code, your NPM code, NPM code. Have you ever used NPM link?

 

I haven't, no.

 

So I found this out when I was working on developing a library, a Vue wrapper for a platform called Form.io that I had done some work for in the past. And they have a generic, it's all, their platform is all about forms and APIs and using a JavaScript definition to render forms in the browser. And then they have wrappers around that for like Angular and React. And I was working on one for Vue. you know, I have an application, but I want to be writing it as a library, you know, an NPM module. And so what you can do, and this, I found this was really cool because trying to debug it was, you know, a, a wild library or, you know, installed library through NPM was a nightmare. As what you do is you, if you look this up in the NPM documentation, it tells you how to do it, but you download the library, you know, to a separate location on your, on your hard drive, wherever that may be. And you do, I forget what the commands are, but you go to the directory where your library is and do npm link. And then you go to your parent app that's using that and there's another command that you run. And basically what it does is create some symlinks

 

Okay.

 

for you through node modules. I forget what it is. And I'll find the documentation and put it in the show notes. But the long and the short of it is that basically you have your npm install library separately that you can debug. exactly the same way as if you're debugging your front end code. So you're dealing with source and not, you know, a minimized code or

 

Yeah.

 

compiled code. So it's an awesome tool for when you're, you know, installing a library, even debugging one, I can think of one that wasn't working. And I used NPM link to go through and see, okay, that's what it is. But that's an awesome tool for, for debugging NPM, what would normally be NPM installed code.

 

Oh nice, yeah, I'll definitely check that out. That sounds great.

 

Yeah, very useful. I tend to get nervous if I can't debug and step through code or look at it. You know, I'll use the... you know, the console log or, you know, Laravel I mentioned uses DD or DDD. You know, it's dump

 

Mm-hmm.

 

and die to dump things out. I've started working with Astro lately. I talked to Fred, shot from Astro, not too long ago, which is a... You know, it's a framework for your static site with sprinkles of JavaScript and ILS type approach, which is all the rage these days as the pendulum swings back and forth. And they use, it's interesting how you can use, you've got your node code up in the top part using like front matter and then you've got your templates. And so

 

Mm-hmm.

 

since that's all running in node, I haven't set up a node debugger. So it's been sort of frustrating that I can't step through. some of this stuff, but they have tools. They have a built-in debug component, which is pretty cool.

 

Hmm.

 

And so you just, it works just like a view component. You know, you import it in and make it available just like you would anything else. And then in the template portion of your component, you put it, you know, your brackets like a debug element. And then in curly braces, you put what is it in your data that you're getting that you want to see. And then it just dumps it out on your screen, you know, in JSON format or whatever the format is. So that's that in console log is just. the best way that I've been able to debug in Astro and it worked, it's not quite as nice as step debugging but it works and you know, gets done. But it's nice when the tools, the framework have built in debugging components for you that allow you to dump and easily see stuff for sure.

 

Yeah, that's kind of, it's interesting. When I ran into an issue with Next.js, which is a React meta framework. So they have some functionality where you can kind of like get server side props and it grabs it before the page, but you know, before actually like rendering to the client. And I was having an issue with that process, but because it was happening in servers, like within Next.js is like server side, it wasn't happening in the browser. So I couldn't use like, replay to debug it, I had to go into the actual server code and start to add logs there and do it in my terminal. And so it's nice when, if a framework does kind of abstract some stuff away, when it gives you tools to get some of that functionality back. So I was gonna check. Did you mention Fred Schott? Did he, in Astra, was there another project that he worked on before then? It was like a package, or something like that? It's on... I think

 

Uh,

 

I saw him

 

yes,

 

give a talk a few years

 

I can't

 

ago

 

remember.

 

about it. It was

 

Yeah,

 

something

 

he mentioned

 

pack.

 

in

 

It's

 

the,

 

OK.

 

sorry. He mentioned in the interview where he'd come from his history. I'd have to go back and find that. But I cannot remember where he came from.

 

Yeah, no worries. I just, I was curious if it was the same person. Um, I think I remember seeing him give a talk, um, a couple of years ago about something like that, but I, I've heard, I've heard, I've heard of Astro. I haven't tried it out yet though, but I hear good things. So.

 

Yeah, it's really neat. I had him on. So for those who are wondering, it's views on view episode 195 from September. So last month I was on the recording today. Oh yeah, it was great. So Astro's, you know, we've talked about it. I had him on just because we've talked about it so many times on here before. Just to give a high level overview. And no, I'm not on their payroll and I'm not a dev rel for Astro. I just, I just happen to like

 

I'm just

 

it and

 

trying to make

 

actually

 

sure

 

use

 

that

 

it.

 

I'm not getting

 

The idea is that

 

the

 

it's a

 

idea

 

static

 

that

 

site renderer,

 

I'm not a typewriter.

 

but with everything coming server-side rendering. But then what you can do is you can plug in the component of the framework of your choice in your page as sort of an island of functionality if you want. So you could add a React component or a Vue component or a Svelte component or an Angular component so that you're getting all the benefits and speed of having everything server-side render but then just adding in the JavaScript as compared to downloading a whole Vue. you know, JavaScript framework or framework du jour, you know, into your browser. So that's a whole idea behind Astro.

 

Okay.

 

And they, I know that as of when I spoke to him, one of the other features, and they've mentioned this in their documentation is that they can also have it be dynamic. They had some capability where you can be dynamic and run some code so that every time you go to a page, it's actually pulling code from the backend. But, Unlike say Nuxt

 

Mm-hmm.

 

or some of the other frameworks currently it's an all or nothing You know you can't have some site statically pages statically rendered in some site synamecs all or nothing So I'm assuming they're gonna add that function elevator. I believe so, but anyway, that's

 

Anyway,

 

Astro

 

that's

 

and

 

that.

 

and What it does

 

Yeah, no, I like Nuxt a lot. I've used that for a couple of different things with the universal rendering. Actually, there's a Nuxt Ionic component module to be able to

 

Oh.

 

create Nuxt apps for mobile. Talking about that at Next Nation, but it's really interesting. I feel like there's been so many advancements and kind of innovations with how things are rendered in terms of incremental. We're seeing like React server components. There's universal rendering. So yeah, AstroSan sounds like it's right along the line with doing some cool stuff there. So I'll have to check that out.

 

Yeah, in the past, so I've had Daniel Rowe from the core team

 

Mm-hmm.

 

on a couple times to talk about next three along with a guy named Drew Baker, who drew works for an agency called Funk House in the area. And we talked all about, you know, all the upcoming stuff. And I haven't I've used next some in the past next to haven't done next three, except for the very basic stuff I did for my view mastery course. on the introduction to Next 3, but that was about as basic as you can get. And I'm listening to these guys talk about all the things you can do on the server and it blew my mind. I was, you know, I said, you guys talk, sounds great. Yeah, sounds good. You know,

 

I'm

 

because

 

going to go.

 

I haven't even gotten to that level of complexity of what I would do with Next for sure. I tend to be, you know, coming from the PHP background, I tend to like to use that as my framework. language of choice. And now you have, was it last week? A couple weeks ago I got to interview Taylor Otwell, the creator of Laravel, and how they have integrated view and in particular inertia.js if you've heard of inertia.js.

 

Yeah.

 

So you can use Laravel in the background and view in the front end and inertia just hijacks the post request and passes everything back and forth for you really quick.

 

Oh wow.

 

So that's my sort of... framework of choice just because of comfort and knowledge and ability to use it. But yeah, Nux

 

Yeah,

 

gives

 

yeah.

 

you, the stuff I'm seeing with Nux 3 is just crazy in terms of the flexibility and sort of micro-control you have over certain routes and certain pages and how you want to render them and when you want to render them and so on.

 

Yeah, there's the defined page meta. You know, there's a lot of just like built-in kind of like page utilities that I, I, again, I wish I had something like more exciting or like more complex to build, like to try it out with because I think I've just scratched the surface with kind of playing with it and then playing with Nuxt Ionic as well. So super interesting. But yeah, PHP, my only experience with that was digging into WordPress, like,

 

Uh huh.

 

themes and manually editing a few lines here and there

 

Right,

 

because

 

right.

 

the theme didn't give me an option in the UI. So I had to go in. I was making WordPress sites when I was in college and things like that. So that was kind of my first web development

 

Mm-hmm.

 

type stuff was plumbing in PHP WordPress, but that was about it.

 

I can date myself and that I started working doing websites initially just straight HTML. There's a book, HTML goodies and the guy had JavaScript goodies too and I don't remember his name but he basically said I'm going to dig in and figure out how this works and then write about it and that was how I learned about it and then I can remember when PHP was personal home pages. You know that's where PHP comes from that was an acronym by a guy named Rasmus Lerdov. and then it took off and became Fili. But I was dealing, doing my first website stuff I ever did outside of that was Frontpage 98.

 

Mm.

 

If you've ever seen Microsoft Frontpage, the first iterations, you know, it was like, you could look at one site right away and say, that's Frontpage, just because

 

Yes.

 

of the really horrible graphics and images.

 

Yeah.

 

But yeah, and then, you know, I got tired of back in and said, hey, Front is more fun because I can see what I'm doing. You know, I can see what I'm changing. I can make things dynamic. I can add better functionality. and do it easier. So anyway,

 

Yeah,

 

enough

 

that's the

 

of my story.

 

back. Yeah, back when I saw my undergrad, I did journalism. My first career was I was a newspaper reporter.

 

Mm-hmm.

 

And at that point you learn how to make websites because it was like the, and it was just the web version of the print. It was literally like, just recreate the print. I would also do pagination for the print. And they're like, okay, just recreate it. And so they would teach you as a journalism major how to make these like static, very static websites, you know, just to be able to publish. to the web. And that's kind of how I first got into it. And it's changed so much, you know, like, I mean, obviously, like, web apps are a whole different level now. But back then, it was kind of just a, oh, yeah, we're just, we're just taking the content, we're publishing it, like, make it all line up good, the same way that you do in Quark or, you know, whatever, in Adobe InDesign or whatever it is that you would use for print. And that's how I was kind of my first exposure to it. And it's a... It's really like, you know, like kind of just like a page. It's literally was like a page. Now everything is single page apps, right? Where you have so much going on, but it was, it's kind of fun to go back and think about how it was at that point. So.

 

So are you basically just editing raw HTML files and pushing them to a server

 

Yep.

 

with an FTP client type thing?

 

FTP exactly. Yep. And then they try to make it and actually talking about debugging, CSS is like, there's no

 

Ha ha ha.

 

error messages. There's no like, there's nothing to tell you what's wrong. You'd like, that was my first experience with trial and error debugging was CSS and just moving things around. And I would always go and try to read more about it. And so, but yeah, at least like, you know, Other, now you have some different tools and things in your IDE, but that was the original, there's no error message. There's no indication of what could possibly be wrong. It just doesn't work the way that you expect.

 

Well here, I'll see if you remember this. Do you remember what there was with the first browser DevTool was before they were built into the browsers?

 

Oh, no, no, you got me there.

 

It was a Firefox extension called Firebug. And so...

 

Oh my gosh, I should have known that because the replay

 

Yes.

 

people probably have talked to me, probably know that or

 

Right.

 

talked about it.

 

Yeah. So I was living in the Drupal world at the time and I can, I can still remember when Firebug first came out and I was like, Oh my gosh, I can see my source code. I can see this. I can see my CSS and you can play around and then hover over things and add borders. And then there's dev tools you can get in the browser. You could, you know, add a border to an element or do this, just a whole ton of stuff.

 

Mm.

 

But you know, it's sort of like jQuery is to JavaScript and that Firebug is like, Oh, this is so cool. We got to build this into the browser. And so now, Now you have dev tools in any browser.

 

Yeah,

 

So

 

being able

 

yeah,

 

to

 

that was.

 

change the CSS or toggle

 

Mm-hmm.

 

the CSS in DevTools and then see the page change,

 

Yeah.

 

that was a game changer for me because it wasn't trial and error of republishing. I could actually change the values and you can export it and you can save it. And so, yeah, it's come a long way for sure.

 

Oh yeah, absolutely. Some of the layout tools and grid and flex box. And that's a whole different discussion

 

Yeah.

 

for sure. So, all right, well, we need to start getting wrapped up here before we move on to picks. Is there any other tool or overall process you want to talk about?

 

Um, well, we covered a lot. Um, no, I think,

 

We did.

 

you know, just, yeah, to kind of reiterate, I think it's, don't be like a, I was always afraid of debugging to the point where I would just like, you know, avoid it or like ask somebody else for help, or it didn't, or just kind of dread it a lot. And so I've been able to change that and become more excited about when I come and cover a bug and you feel more like a, it's an opportunity to learn. And you just get that through practice. And so. For me, going into open source projects and looking at issues and trying to figure out what I could debug, I ended up finding a bug in XtalaDraw and I was able to figure it out. Stuff like that just helps you kind of get practice with the different tools and the different processes. So that encourages you to maybe go do some bug hunting and just kind of have fun with it.

 

Right on. Alrighty, well, thank you for coming to talk about debugging. It is a geek passion of mine for sure, being able to debug stuff. So that's, learned about some great tools. Great tools. So with that, we'll move on to picks. Picks are part of the show where we get to talk about anything we want to, within reason of course. May or may not be tech related. Anything, I will go first and I will do the dad jokes of the week. I think I need to do a theme song for that, the dad jokes of the week. So, first of all, so you know, I live in a neighborhood like most people do and I really liked a lot of my neighbors and there was one particular one, I thought they were really great people until they put a password on their wifi. Really? Fun fact. Did you know, you know, a lot of people wear T-shirts. And did you know that the word T-shirt itself is actually short for Tyrannosaurus shirt? It's because of the shorter arms. Right? So I have a little, you know, I do, I like to do CrossFit and one of the things we do a lot is burpees, you know, we drop down to the ground and so on and my daughter gave me a sticker that I have in my water bottle that says T-Rex hates burpees, you know, because he's got the short arms

 

Hehehehe

 

and can't get down. And then finally, I was having a conversation with my son the other day and he asked me, he said, Dad, how do you cast spells? I said, why you just follow the instructions? He goes, which instructions? I said, yep, those ones.

 

That was very timely for Halloween.

 

Yes, yes, I like the Halloween jokes are good for sure. So anyway, those are my picks. What do you have for us to hear you?

 

Um, yeah, so, um, this is kind of like a, it's actually an app, but it's something I've been using, um, it's called centered centered app. Uh, I have a couple, I actually met some people who work on it, but it is a kind of like task management, time tracking, like focus kind of app, um, it's free. Uh, it's centered.app. And, uh, I found it super helpful for kind of just, um, organizing my day and they have rooms that you can go into and kind of work together on different projects and stuff. And, uh, so I've been in. using that. And another thing that I got recently that I'm really excited about is this giant rainbow corgi. You can't see it, but it is. I love rubber ducks. Sorry, I like to debug. My desk is covered with toys. I have actually pterodactyl ducks for your dinosaur joke there. So I love to collect different types of rubber ducks. And there is one that is a rainbow corgi And it's a Jason Langsor from Learn with Jason made them. And I'm obsessed with it because I also love corgis. And so that would be my other pick is if you are looking to add to your rubber duck toy collection, there's a rainbow corgi ducks now available. So.

 

Yes, Jason actually lives very close to me here in the Portland area. Never actually met him in person, but we've talked and he's very close to me. But you just brought up an interesting point that we missed talking about when it comes to debugging, and that's rubber ducking.

 

Oh

 

So,

 

my gosh.

 

can you explain what the term means?

 

Yes.

 

I can tell you what I've read about where it comes from, but just the general term, because I use it a lot.

 

Yeah, yeah, no, I can't believe I can't believe we missed that. But yes, the rubber ducking is essentially the idea where you explain or talk out your problem and talk through it to a rubber duck or any kind of really like inanimate object. But the idea is to get you talking out loud and put your thoughts into words in order to articulate what it is you're trying to solve and hopefully get to a solution sooner by being able to organize your thoughts.

 

Yeah, I mean it doesn't have to be to an animate object. It can be to a person. I can think of

 

I guess

 

times

 

that's

 

where

 

true.

 

I've been

 

Yes.

 

talking to a coworker or a boss and I'm, hey, I need help with this. Well, what's the problem? You start explaining it. As you're explaining it, you sort of figure it out and I'll say, okay, sorry, I'm rubber ducking right now. You know, you're my rubber duck. And I'm like, yeah, great. No problem.

 

That's true.

 

You

 

I

 

know.

 

think it's more fun if it's a cute little rubber duck though, maybe.

 

Is it? Yeah,

 

I don't know. I just didn't...

 

I'll have to get some rubber ducks, some actual rubber ducks. I have the no button on my desk. I think I'll have to go buy a Rainbow Corgi rubber duck or something like

 

Yeah,

 

that.

 

I will. Oh, baby, maybe it's just my excuse to get toys, honestly. But.

 

For sure. Alrighty, so with that we will wrap it up. Thank you very much to C for coming on and talking about debugging. It's been a pleasure. I know I've learned some things and hopefully people listening have learned some things.

 

Yeah, thanks so much for having me.

 

All right, with that, goodbye, and we will talk it next time on Views on View.