Kent C Dodds: Normally you would npn install the loaders themselves and so, we'll go to, I'm just going to go to the package JSON and well, yeah forget it. You would install these loaders and then in your web pack config, we're just going to copy this loader that we have and alter it a little bit.
So this is just in our module loaders and we'll add it for our test it's going to be all files that end in CSS because for us we're just using CSS we're not going to use preprocessor. So we'll just say anything that ends in .css I want to load through the css loader.
But remember the next next thing after css loader it needs to go through the style loader so it gets injected into the DOM. And this is maybe a little counterintuitive but you might think that style should go there. That's not actually how it works. It runs from right to left.
So it'll first go through the css loader, then it'll go through the style loader. And because the way that our project is set up if we look in our index HTML we have this link for our index css, for the css for our entire project. We don't want to exclude our node_modules.
And actually, most of the time, for CSS, if you're going to be using node_modules, you don't want to exclude those node_modules unless you're going to include link tags explicitly on your page. And so here, we're going to remove our exclude node_modules, whoops.
Kent C Dodds: With the dependencies installed and the loader specified that's all that you need to start being able to require CSS.
Any questions about that? Okay I'm trying to think of a good way to, practice but I think it's fairly straightforward. The one other thing that we need to do is now we're still loading this in our, the same way we were before. We're not actually explicitly saying hey I want to require that CSS It's just still in the regular HTML.
And so in our app file where we have all of the requires for our app, we're going to add another require up here that says require, and this harkens back to what we were talking about how require is resolved. But it'll be todomvc-app-css /index.css.
Kent C Dodds: So actually if you run your def server right now, then you should be seeing a style tag injected into your dom, oops!
I have something on. I have the server running already. Okay, so you refresh here, you go to your elements. In the head and you'll see we actually have it loading twice once with that link tag we need to remove that. And then again with the style tag.
Kent C Dodds: And it's just injected right there.
I am waiting for a specific question that somebody is bound to ask, so I'm just going to sit here and wait for somebody to ask it just kidding. Okay so the, yeah so the question that I hear frequently about this is a question about performance because this is happening at runtime.
Let me show you where performance actually becomes a real issue. And that is if I delete this link tag here. So we're no longer loading it just normally it's being loaded at runtime. And if you think about it it's being loaded at the time that the script tag is being loaded right.
Because that's where our CSS lives now is inside of our bundle JS file. And so now if we refresh the page you're going to see this flicker and that is really annoying. You see that on like old bank websites and stuff. Not on to do NVC and so there are a couple of things that you can do to combat this.
Anyone have questions about that? Okay, hopefully we covered loaders well enough that. Well let me just ask does anybody want to have a little bit of time to practice this themselves? Okay, cool. So the branches exist and the diffs are there for your perusal. I'm going to move on because we are still behind.
Who here has heard of this? Hot Module Replacement? Yeah, so this is the thing that the react community is bragging about, right? Because like they've had it for a year or so or even more. I'll be honest, I actually don't use hot module replacement myself. I've used it a couple of times.
I don't use it in my app. But from what I understand, once you start using it you can't go back, and it's totally amazing and incredible and stuff. This app does have hot module replacement. Let me explain how it works a little bit. So we have our main module here, is here actually sorry before we do that everybody can go ahead and check out the next branch.
Student: Before you do that somebody just asking could you just show them the bundle js file now?
Kent C Dodds: Yeah great thank you for asking that, yeah. So if we build, we'll build the dev because the production bundle will not be easy to read. But yeah, if we look at the bundle and we find our todomvc.
What was it called?
Kent C Dodds: This thing.
Kent C Dodds: So right here. Yeah, it's actually probably still not easy to read. But actually, if we take off source maps then it might be a little bit more straightforward.
Kent C Dodds: So with that rebuilt.
Kent C Dodds: Okay.
Kent C Dodds: Even with that it's not super helpful, but this is basically this is what the CSS loader does to it is it creates a module that has a require statement for this CSS based thing.
Goodness yeah, yeah, it's kind of lots of this CSS stuff from the css-loader and the style loader, they actually both add runtime to make it work. Right here is where your actual HTML goes is inside of this exports.push. So it's like the export it is an array where you have the module ID and the string of your CSS right inline there.
We are actually going to talk about how to extract that using the extract text plugin. So that you can leverage caching of that, of your CSS assets and stuff that will come a little bit later. Yeah it's kind of like yeah it's doing a lot of complexity stuff under the hood.
So it luckily you don't have to really worry about it because it just it works. I've never had a problem with the style loader. Other than what I talked about with the critical CSS stuff but that's a problem that you have with CSS in general, so.