Introduction to Dev Tools, v3 Introduction to Dev Tools, v3

Sources, Application, & Memory Panels

Check out a free preview of the full Introduction to Dev Tools, v3 course:
The "Sources, Application, & Memory Panels" Lesson is part of the full, Introduction to Dev Tools, v3 course featured in this preview video. Here's what you'd learn in this lesson:

Jon uses the Sources panel to view a full IDE, access a step through debugger, and persist changes to disk. The Application panel can be used for viewing application storage, checking PWA features, and clearing the cache. Generating memory snapshots and how to find and fix memory leaks using the Memory panel is also covered in this segment.

Get Unlimited Access Now

Transcript from the "Sources, Application, & Memory Panels" Lesson

[00:00:00]
>> The sources tab, this is one that I feel like it's kind of underrated. It's basically a full ID and so over this course we'll learn how to do. We'll learn how to use the courses tab for step through debugging, which is really cool. So instead of just console logging, we'll be able to put a break point, we'll be able to pause the whole execution stack at that break point and kind of move around.

[00:00:23] We can check the call stack, like how we got there, what functions got called. We can keep an eye on certain variables, like watch a variable and see how it changes over time. But we can also use this really cool thing called work spaces, where we can drag our project into the dev tools, and after we set it up correctly, everything that we edit will actually persist to disk.

[00:00:43] So normally if you're in the elements tab, and you're messing with the CSS, I don't know who's gotten into this before. This happens me all the time, so I'll be like working on design I'll go into my elements tab and I'll get it perfect right. It's like the CSS look at the site looks like exactly perfect, but I've been working for like an hour.

[00:00:59] When I'm ready to ship it, I'm like, I don't even remember what all I changed at this point. Like I added so many classes and I added so many selectors and styles like, it's really difficult to figure out what you change. And so workspaces can be really cool cuz you still get that instant feedback of working in the sources or elements tab.

[00:01:15] But you can actually hit like Ctrl S or command S and it'll save it to disk, so we have a whole exercise on that for later. You got the application tab, I usually refer to this one is just storage as like a way of thinking about it. So this is where you'll come probably primarily to look at all the different ways we have of like caching and serving things locally.

[00:01:36] So that's like local storage, session data, cookies, index db, all sorts of stuff like that. It's also the place that you come if you have a progressive web app with a ServiceWorker. So if you have a service worker, it also has a service worker tab, where you can see is there a worker is it being registered, what it's doing all sorts of stuff like that.

[00:01:55] It's also maybe most commonly used to come into the storage and click clear all site data. That's probably what I use it for the most right so when you're like, you know you're in a weird state and you cache something or you're messing with sessions or cookies and it's everything's bad.

[00:02:11] You just come in here click clear site data, refresh the page and get a nice clean start. We've got the memory tab, so this one is very specific to your memory consumption. But it's really cool, so you can take a heap snapshot, which is like show how memory is currently being used in my app.

[00:02:30] You can do a timeline so you can like the profile or the performance page, you can record over time, and you can do stuff and you can see what you're doing that's using memory or not. And then there's this new tool which is like probably one of the things I'm most excited about, which is you can allocation sample.

[00:02:46] And that'll help you now that you have a memory leak hypothetically, it'll help you figure out what job script code you're using that's actually causing that memory leak. Because in the past it's been really easy to find out that you have one and it's been much more difficult to figure out why you have one.