This course has been updated! We now recommend you take the Introduction to Dev Tools, v3 course.
Transcript from the "Saving Changes in Workspaces" Lesson
[00:00:00]
>> Jon Kuperman: Cool and then we can save changes to disk. So this one is like it's probably the biggest example in the editing and it has come a really, really, really long way. Having said that, it still isn't gonna be perfect for your workflow. But this is where we get into this concept of like using the dev tools as your main IDE.
[00:00:17] So not having an editor open just using the dev tools. So what we can do is we can go into the sources. I'm gonna close all of these other tabs here. Actually, another kind of handy thing if I have stuff open. This happens to me a lot where I'll have like a million things open here.
[00:00:31] So just like in editor, you can right-click and you can do things like close, close others, close to the right or close all. So I'm going to close all these tabs and let me make this a little bit bigger here. So what's going on here is we can see that for this page.
[00:00:44] We're getting all these files. Here's a CSS file, the JavaScript file, all those things. I'm gonna make this a little bit bigger. I'm gonna go to this file system tab over here. And so under file system, we've got this concept of add folder to workspace. So before we do it, the kinda concept here is that Chrome is getting all these files from your local host and then you can give Chrome a folder of your actual code.
[00:01:10] And Chrome will start really trying to intelligently make mappings between those things. So it'll be like okay, a style that's CSS comes down and the folder you gave me also has a style that's CSS and they're the same. So now, I'm gonna map them together and it will map as many files as it can together.
[00:01:25] And once mapped any changes that we're gonna make actually persist to disk as though they were written in your text editor. So that's the kind of high level view, let's like walk through it together. Let me open my finder, so I've got this work space filled out. So here is just where and we'll get into this and I'll help anybody get setup.
[00:01:46] This is the sample app that we're working on, Mastering Chrome deaf tools and I've just get cloned it that's how I have it on this. I get cloned it into this folder, so I've got this is where I'm serving from. If I go to my terminal you can see, I'm in that mastering-chrome-devtools.
[00:02:00] That's where I run npm start to get the app. Is everybody good on that so far? So I have this like running npm start. It opens this local host thing. That's kind of what's serving the content. And so what I do is I go add folder to workspace and then I'll go in my finder, and I will find that Mastering Chrome DevTools, and I'll click Select on it.
[00:02:22] So basically, what I'm saying here is I'm adding this folder. This always bites me. If you're not seeing it right away and this will happen when you do the exercise, it's because of this little warning. I don't, maybe that's easy to see for some people. I always forget about its existence and it's saying.
[00:02:35] So basically, this is getting sensitive. So now this is like I'm adding something, which is in turn giving Chrome the rights to write to my file system. And that's what we wanna do, but Chrome its required that every time you acknowledge that security risk. So I'm gonna go ahead and say, allow.
[00:02:51] And now we can see, so we still have the page. This is the stuff that is actually coming from the server. But now in the file system, we can see, I just uploaded my whole folder here. So you can see all the same stuff that you'll see when you get crown the project down.
[00:03:04] What's really unique is you'll start noticing these green dots on a lot of these files. You'll see a green dot here. And if I go back to the elements tab, I'll start seeing green dot next to all these rules. And so the green dot means it's sinking that it is mapped.
[00:03:20] And so that means that anything that I change in here will persist, will be written down. So let me just show you an example to kind of visualize it. So I'll scroll back to the very top and I'll select my my nav. So I've got my nav here.
[00:03:34] I've got my nav here and it's blue. And if I open my Visual Studio Code and I go to my style.css, this is just local on my computer. I can see I've got my nav here and it's blue. So that makes sense. That's the CSS that I've written and then this is where it's being authored here.
[00:03:51] But now that it's mapped, if I go ahead and I change this to red and I hit enter on it, we actually go back to the file system and we see it's been changed to red. So this is exactly doing, going to kind of make it this way, so we can do like
[00:04:09]
>> Jon Kuperman: Get in there. Do pink and it changes to pink. So this is now, we're in this mode where we're authoring all of our code and it's actually persisting there. And if we look in git, we'll see that there's a real file system in change there. So kind of come back here, this is where the caveat start.
[00:04:25] So it can do all the CSS stuff. You would notice that if you did something like change the nav to be a div or something like that, div class. And then I refresh it, it's not. Whoa, sorry, still have a break point.
>> Jon Kuperman: If I refresh it, it hasn't persisted to a div.
[00:04:46] And the reason here, it's pretty straightforward when you really think about it. When we look at the site, we'll see I'm not actually serving HTML. I have a node app that's serving a template language like Mustache or something like that. But the big part is that remember when we at the beginning of this, we learned the difference between HTML and DOM.
[00:05:03] HTML is kinda what we author. DOM is what Chrome turns it into. So over here, we're editing DOM. This isn't anything that's been authored. This is what Chrome's kinda done with it. So to kinda keep the easy rule of thumb is anything you edit in the styles tab instantly persist to disk, no problem.
[00:05:20] Anything you edit in the elements on the left side will not persist to disk. If you want to, you can go back into sources and you can open any file you can open in sources including your HTML. Those will persist to disk just fine. But they kinda caveat is like if you make a change in here like changing an element, changing a class name, those changes don't save.
[00:05:41]
>> Speaker 2: There's a question obviously about the SAS-
>> Jon Kuperman: Yeah, this is great.
>> Speaker 2: [INAUDIBLE] build processes.
>> Jon Kuperman: Yeah, this is great. So now, we get into these build processes. So the reality is how many of us just sit and write just HTML, and CSS, and send it out.
[00:05:55] That's not how things work. So we all have these build tools like maybe using webpack, maybe using Gulp. And you have maybe a CSS preprocessor like Sass or LESS or you have templating languages like Mustache like we have all these kind of abstractions that we use day-to-day. So when I gave this course a few years ago, the answer was pretty much a resounding no, it won't work with that stuff.
[00:06:15] But it's come a really long way. So yeah, if you are using Sass, if you're using SCSS, it will work just great. Chrome has built-in support for that, so you'll just drag in your project with your Sass files. Chrome totally understands and can make those transitions. So any color your change will be written to the corresponding Sass file.
[00:06:34] As you get into other things, more complex build tools like I mentioned earlier create, react app where you've got react which isn't really all that well-supported in Chrome DevTools. You've got Webpack building all this stuff. Things get really complicated. You'll find less and less stuff working there. The way to test is just to drag the workspace in and see what files it's able to figure out and map.
[00:06:56] So assess support is definitely there. Mustache support is coming. Webpack full ecosystem support is probably a way off. I would say, it wasn't coming, except they've just been making these huge strides lately with supporting build tools and then another cool thing to keep in mind is most of these tools rebuild on file system change like that you go in to what them all.
[00:07:17] That'll all still work perfectly right, because any change that you make to your Sass file will reflect on the file system. It'll kick off your build again, so that workflow will work well. I think the way to think about it is your styling, this is really great for.
[00:07:31] If you're using Sass or you're using CSS or anything like that, you can drag those files in and you can start making changes here and they'll persist seamlessly when you get in to your authoring of HTML. So if you're using React or View or Angular, I would guess it's not going to work all that well for changing HTML.
[00:07:49] But it works really well for your CSS. And also now that things are mapped, it'll work very well for your JavaScript too. So you can see the JavaScript has a green dot. Any change I make in the sources will be persisted to disk, as well.
>> Speaker 2: Before you move on to another panel-
[00:08:02]
>> Jon Kuperman: Yeah, of course.
>> Speaker 2: The one next to the file system and that would be persist changes.
>> Jon Kuperman: Yeah, so we've got-
>> Speaker 2: Overrides, overrides.
>> Jon Kuperman: Yep, yeah. So yeah, I will go into that in a little bit. It's pretty cool. Let me go into that. I have some things around it in the debugging section.
[00:08:19] But yeah, so with the content scripts and with your overrides, you can apply really kind of like a script monkey back in the day. You can apply permanent overrides to different things. You can apply it out like a global or like a very narrow scale. Yeah.
>> Jon Kuperman: Yeah, so Samara has a great question.
[00:08:38] So with the nav element, why couldn't I persist then? And so this will be a little bit of a dive, but I just wanna take a look at it. So if i look in my layout, so I use this pug templating language. I make an element and I give it a class, so it's like nav.nav.
[00:08:55] And then express, my node server runs and it takes that pug element and it turns it in runtime into HTML and sends it down. And then the browser takes that HTML and it turns it into this DOM thing, which I'm seeing here. And so this is isn't my HTML and like a good example would be this.
[00:09:13] If you've made like a React app or a view app or whatever, usually if it's client side rendered, you only serve with one div. You'd be like div ID equals root and that's like what you send down, that's the HTML you write and then React kinda mounts on that and starts making its own dynamic stuff.
[00:09:29] So as I would try to edit an element in here, Chrome has no way of knowing where that came from right like Chrome has no way of knowing that node turned the pub file into HTML or Chrome has no way of knowing like which React component is responsible for creating and mounting that element.
[00:09:46] So that kind of thing to think about is that if you wanna change those kind of HTML files or anything like that, you can do so. But you'd have to go through the sources this tab open it up and make changes like an editor, basically. So basically, these changes don't persist.
[00:10:00] The ones on the left hand side, because they are like these constantly updating, dynamic, DOM model. I hope that clears it up a little bit. The kind of short and sweet to it is the left size won't persist, the right side will persist and sources will persist.
>> Speaker 2: This is very similar to the situation when you have the CSS that's been transpiled from Sass.
[00:10:20]
>> Jon Kuperman: Yeah, the big thing is that Chrome DevTools has Sass support. So it's just understands Sass. It doesn't understand and I guess with my particular app, it has no way of understanding server side stuff. So it couldn't understand note, because it doesn't even know that note is what's surrounding it.
[00:10:39] It just hits an endpoint and gets back at HTML. It has no idea where that HTML, how it's generated. No, so it used to be. So the way that the workspaces used to work was you would drag the folder in, nothing would happen. And then as you would open files, maybe it would suggest.
[00:10:54] It would be like I think this is this or I think. And you'd be like yeah, totally. Nowadays, it's like really intelligent. You just drag the folder in. Everything that can go green goes green and you're good to go.
>> Jon Kuperman: Can you do the elements tab and the sources tab at the same time?
[00:11:10] No, you cannot. The only dual tabs that you can do are you can open the console drawer over any other tab.