React Developer Tools

[00:00:00]
>> Steve Kinney: So with that, we are going to jump into the repo, get a sense a little bit of how it works. We're going to start with the simple, easy, quick wins that you probably in your heart of hearts know, and yes, they will seem a little like contrived, right? Because some of them, like they're tiny apps, it'll seem like, well, I don't have that in the application component. Sure, you have it like some version of that problem down the tree somewhere in a smaller version, it is in your app, I guarantee you, if any of you tell me you don't have it and send me your codebase, I will find it.

[00:00:32]
Right, because I have it. We all have it. We, because sometimes it's just like stuff changed later and you don't even know. But we'll talk about it. So let's go ahead and take a look at our repo because there is some tasting notes there. Like I said before, we have a page earlier that has all of our notes and stuff and more than you would ever want in case you're curious, but then there are also the practice lab repository, and if you don't have the React developer tools, go ahead and open another tab and install those as well.

[00:01:06]
You might also choose to, if you go into here, you can like choose which ones you want like pinned. And you can like pin that one up here as well, which looks kind of funky in dark mode, but I promise it's okay on an actual React site. If I go to a React page, you will see it turn orange. That's on a non-React page. Cool, cool, cool. And then if we go to the repo, I'm on the live coding branch, which at this exact moment is no different than main, but it just means that I can do stuff, push up those changes, and not ruin it for people who watch this course later.

[00:01:43]
So the two ways to kind of use this is to do npm run examples, which will give you the ability instead of making me make you download 11 repos or whatever, because we're not going to use all of them, unless topics come up. Some of them are just in case somebody asked me a particular question that exists. And so you can pick the one that we're going to use and so like the first one I think that we're going to use is Deep Thoughts, depending on how I change my mind at some point.

[00:02:11]
And then once you have that, you can do npm run dev. And it's a little Vite thing and you can see that you've got the app running here as well, and life is good. And then when we switch to another one, you'll just do the npm run examples, we'll switch to another one. You'll watch me do it. It'll be great. So we have some apps. This is one for capturing your deep thoughts. Because it's not a to-do list.

[00:02:41]
Why would you say that? It's not, it's nothing like a to-do list. You can't check anything that's completed. So it's not a to-do list. I didn't make a to-do list as my example app. How dare you? Everything is a to-do list. Every app you work on is a to-do list of some sort. Cool. And so we can, you know, pop some stuff in here. Let me say, I should make a to-do list app. Capture that thought and it goes down on the bottom.

[00:03:13]
It's the default. Let's have an app that we can play around with. Some tasty notes. I think I have this in slides that we'll see in a second, but we'll just call that reinforcement when I show you those slides because it's here. One thing when you go to measure performance and everything along those lines, we're going to break that rule today because switching back and forth is not a good use of our time, but in development mode, everything will be slower.

[00:03:41]
Why? Because it's doing a whole bunch of fun stuff like measuring your renders and why they rendered. It's doing stuff like when you look at the Chrome developer tools, telling you what component it was instead of the minified name. It's, you know, loading all the store, it's doing a whole bunch of stuff that is, again, doing stuff is slower than not doing stuff. So if you like go pull down your coworker's pull request after you walk to this workshop, you think you're smarter than that person, and you pull it down in development and start like hassling them about how that took a full two seconds, right?

[00:04:15]
Like, make sure you do it on the production build, okay? Because otherwise they're going to like go, I don't know what you're talking about, and you're going to feel foolish. That said, you will notice if you have this pinned, the opposite problem, which is somebody, some site that you use is definitely deploying their development build of React and are being slower than they can be. Occasionally, you or someone you love will decide that they wanted to spend Friday afternoon tweaking their Webpack or Vite configuration, and you will have done it to your own app.

[00:04:57]
So sometimes if you were going to React abnormally, keeping that pinned is useful to make sure you didn't mess up your own build tooling. Right? And also make sure that we don't shame people. Once we have this installed, right, we can go into our developer tools, and we can see an error message from a Chrome extension that has nothing to do with us. So we'll just go away with that one. I don't even know which one that was.

[00:05:23]
At one point I figured it out, but I don't know anymore. And depending on how many of these fun things you have installed, you should at least see somewhere both components and profiler. Components is useful because it gives you kind of the like, what does your actual component tree look like, which is also as you hover over it, super nice at figuring out what file do I need to edit to do that ticket somebody just gave me.

[00:05:54]
Not necessarily the most important one for us right now, but it's there and it's useful. You can also do like a version of, you know, the kind of Chrome inspect element, but you're inspecting the component where you can see all the props that I got and the hooks and everything and who rendered it. So it kind of almost like the call stack for it, so on and so forth, like what file it is in your codebase, right?

[00:06:19]
Nice tool, not necessarily performance focused, but like, it was there, it's worth looking at. It's, you know, as long as you've got it for the other stuff, you might as well use it. You can, you know, go over to the dev tool version, you can log the component data. You can even, source maps are not bad. All right, I expected worse, because I didn't go out of my way to optimize that. Cool, cool, cool, but we care about the profiler where you can do a few things.

[00:06:53]
You can like record kind of like you can in the developer tools, right? So I should make a to-do list app, capture thought, so on and so forth, and I can stop it, and you can kind of see effectively, okay, here's the application of the container, you see what, here's me typing into an input field. You can see that like for adding one new thought, it's not a to-do, it's a thought. For one new thought, I seem to render a lot of thoughts.

[00:07:24]
Right, because this app is intentionally bad. And so we've got that kind of in place as well, and we'll fix some of these things as we go along, like which one kind of took the longest, so on and so forth. When I did the last refactor, I don't clear out that input, but we can do that later. Cool, cool, cool, and you see everything that's happening there, the timeline, so on and so forth. The one feature that is a little bit hidden that I love is you kind of go in here, there's a few different options, right?

[00:08:04]
You can change the theme if you really want to. This right here, highlight updates when components render, right? And now you can kind of see, as I do something, everything that got triggered to re-render flashes. And what's interesting here, and you can actually see if you type a lot, like how many times, right? What's always interesting here is like, did stuff you don't think should have re-rendered re-render, right?

[00:08:39]
If so, that's a possibility of a place to optimize. Again, do not become the person who goes through everything and starts to optimize every single one of them away because like, you could make the world a better place. You could. You could also like cause a lot of like, you know, like damage, like, because you don't really, you haven't really thought it through, and then also, you have to work with these people.

[00:09:06]
So there's a careful balance, but it is useful both if you're working on a new feature and just want to make sure, because again, some of the like worst performance like quagmires that I've ever seen are no one smoking gun. It is a whole bunch of things accumulated over time. So like, if you're working on something, it is worthwhile to see, like, especially when things are still in that malleable state, if you can adjust it at all, absolutely do that.

[00:09:35]
Otherwise, like, it's a sign, right? Like, why do I have to re-render the duplicate button, right? If nothing about it is changing, right? That seems weird, right? And some of these are like components that I made, so you're kind of out of luck. And like you can kind of begin to trace some of those things down. So I always think that this one is super useful and if I'm not mistaken, you should only really ever see it if the tools are open, and it's in development mode, then you will see it, which is always fun.

[00:10:08]
I have had a few apps where I was like, I think I had a Chrome extension that like was using Redux and I was working on a Redux app and they didn't put their thing into production mode and so it was like littering up my developer tools and I was very salty about it. But this is there and it's super useful, and again, not a lot of effort to kind of get the nice parts about this. Again, I really like that.

[00:10:37]
If you need more space, you can tweak all those things. I don't touch most of these, but they might be useful for you if you need them. So on and so forth. You can also record why each component rendered while profiling, so that's only when you're running that. So let's go ahead and we'll say record. And then theoretically we'll stop it. And you will get this like why did this render? And you'll see what props changed, right?

[00:11:09]
Or if context changed or something along those lines, which gives you like some amount of a like insight into what went down and why it went down. Now, again, the act of recording that takes some amount of time, so if you have that on, and then again you're trying to hassle someone on your team, know that you just made the own metrics worse. Trying to be smarter than everyone around you and so don't do that.

[00:11:33]
I think you just answered that, but someone was asking, does the highlighting feature impact the render times recorded by the profiler? Yeah. Everything will be, all the numbers will be bigger, right? Because every doing stuff takes more time than not doing stuff, right? So every, yeah, the act of measuring is like a quantum physics problem. The act of observing it makes it different, right? Even in production, like the act of observing it makes it slightly slower.

[00:12:05]
You know, and in production, if you want to get a little bit more insight, you can do stuff. This involves some tweaking to your build tooling that is going to be different between different versions of Webpack and or Vite and or, what was that React starter thing that we all used forever. Create React App. Yeah, create-react-app. The one that was literally when I grabbed the apps from the previous version of this course, I had to refactor that up that one, the one that I was literally thinking about yesterday.

[00:12:33]
You can do stuff like swapping in the production build, swapping out React DOM for React DOM profiling and scheduler tracing, yada yada yada, as like an alias. So like if you ever use Vite and you use like the resolve alias. I think Webpack has something very similar these days. Again, according to your build tool, it's going to be slightly different. These will, again, are they slower than the not version?

[00:13:05]
Yes, but they are closer to like a production build, so on and so forth, of getting to see those things. But again, anytime you're measuring in any way, you are in some way, shape or form slowing things down. That said, let's flip the opposite of this. Sometimes you want to slow things down, because I'm going to make some assumptions, many of you, if I just look around the room, are on pretty good Wi-Fi, using pretty nice computers.

[00:13:40]
Right? I have had the privilege for the last almost like seven years of my life to work on like developer tooling where I too have enjoyed a world where 98% of people are on modern Chrome, with like high-speed internet from around the world, in fairness, and like majority like MacBook Pros, right? But depending on like the people using your site, that's probably not the case. So the other thing that you probably want to do as you're like trying to get a sense of, especially if like the reports that you get from your customers about performance, particularly for front-end applications, are never useful.

[00:14:15]
You will get reports like, it is slow. Right. And then it's on you to figure out what that means, right? And then you pull out the app, even in development, you're like, I don't know what they're talking about. Before you go back to the support person and give them attitude, right, because support people are the best. Don't ever give them attitude. If I find out you're giving them attitude, we're going to have a talk.

[00:14:49]
Or you know, product manager, be, you know, say whatever you want to them. Do the following, right? In network, consider playing around with one of these, right, so effectively slowing down your internet. It's only in Chrome when you have the developer tools open. That said, if you leave them open and wonder why everything is terrible before you call Comcast, turn it off, right? Do not be mean to your support people or other people's support people.

[00:15:24]
The other one that you have that is useful is under performance, you can see and we can talk about what these mean as well. A lot of them we're not going to deal with directly, but I will explain those terms if anyone is interested. The other one here that is useful is you've got that network again here, but the CPU throttling, right, which is to basically effectively simulate that you have not a $3,000 computer.

[00:15:50]
Right. And if you happen to not have a $3,000 computer, you're already winning. But for those of y'all who, you know, have whichever ridiculous computer their company gave them because the backend engineer said they needed 64 gigs of RAM, right, you can at least become a normal person for a little bit because nobody needs that. Docker is not an excuse. But anyway, so you can intentionally also make your device slower, which we're going to have to do in some cases because like, other than getting really fictitious with the bottlenecks, right, but like, you know, these are super useful as well.

[00:16:27]
So, yes, measuring stuff makes stuff slower, sometimes you want to make it slower. It's a weird, it's a weird game we all play here as well. So cool, we have all of those things kind of at our disposal, and we can see that this application has a myriad of weird little problems, and there will be some other applications that you will play with that have similar problems. Sometimes I will tell you what they are.

[00:00:00]
Sometimes I'm going to say use the tools and figure it out and let you swim for a little bit, and then I'll show you in a second.