CSS Best Practices

[00:00:00]
>> All right, so the third and final piece of our languages block is talking about CSS and how do we manage CSS inside of our view apps. And so as a whole, the general recommended best practice is to limit all global styles to App.vue whenever possible. And then going forward whenever you have individual components or anything that's a .view file, beyond.

[00:00:23]
After view, we'd recommend scoping it with either scope styles or CSS modules, which I'll go over next. And so here we have a simple component that's called Myredtext.vue. And so we have a template here that has a class red and a normal style block. And so as you might expect, everything in here would apply globally.

[00:00:45]
So if any of the components uses the .red style or the .bold, they would automatically inherit those things. And so while that's okay at the app.vue where you sort of, we all know that that's sort of the global entry point for our entire application. As a whole, it's not recommended to do this because you'll inadvertently end up with side effects, especially as people start refactoring and breaking components up into smaller pieces.

[00:01:07]
This is one of the reasons why we don't recommend doing that. And instead we'll be going over the two methodologies, either stope styles or CSS modules for your components. So when it comes to scoped styles, what it basically allows you to do here is that, on the style block all we add is the scoped attribute to style.

[00:01:28]
What that does for us inherently is it will automatically add a data attribute to our HTML element. And then what we'll see here is that inside of our style, it will automatically append that data attribute as a way to then sort of scope the styles. And make it more specific to the HTML elements that are it's being applied to.

[00:01:48]
Now for those of us who have more experience with CSS, though, while this is certainly a nice technique for helping to reduce the amount of overrides that might happen. When it comes to specificity, it's still possible for something at a global level to still override this in the event that they have something that's more specific.

[00:02:04]
So whether it's dollars, sort of bank important are those sort of things it still doesn't completely protect us from scope creep. So instead, what I recommend is using CSS modules instead. And so this is something that a lot of people don't know about. And so the way CSS modules work is it's just like scope styles, in the sense that all we do in order to make it easy to use CSS modules is you add that module attribute onto our style block.

[00:02:34]
And what that does for us it goes ahead and what we do is we v bind our class. This is the weirdest part about CSS modules. We v bind it and then we're given this attribute called dollar symbol style and then we access our class directly. And so this might feel a little javascipty because it is right we're accessing a style property and then accessing a property called red.

[00:03:00]
And so while it took a little getting used to I think once I show you the benefits here we're gonna see why this is really cool. And so what happens when you use CSS modules is that you will actually go in and recompile the CSS class name into something completely different.

[00:03:17]
As we can see here on the left hand side it first starts by prepending it by default with the component name. So this is why you see the my red text you'll do underscore and then whatever CSS class name you originally have, which in this case is red.

[00:03:28]
Then it'll upend some sort of unique hash on the end of it and so this is really cool because what you end up getting is really specific CSS classes that'll basically never ever have any collision with any part of your application. And so, in case you're wondering, you can customize what's prepended and attended and those sort of things but out of the box with no additional work beyond using the module attribute.

[00:03:52]
And then, binding the style class, basically, get truly scoped CSS that you don't really have to worry about. If app.view has a .read class that dollar sign important doesn't matter, they will never, ever conflict. And so personally I recommend when it comes to styling our components to use CSS modules, because it's a really clean way of doing it.

[00:04:14]
And on top of that, there is even a bonus to using CSS modules. There's a technique called CSS modules, exports, which anyone who's worked with, the spectrum is probably familiar with, but I wasn't even aware of this until adjusts last week. And the idea behind this is that when you use the module attribute, you can actually export variables from your CSS.

[00:04:36]
And use it inside of whether it's your template or actually, to be honest, it would work inside of your script block as well. Because after all, dollar symbol style is something that's accessible now within the JavaScript scope. So as you can see here, I can actually render out the actual grid padding.

[00:04:52]
And so this is really exciting because what this means is if you have, let's say, like a SAS design system where you have different things like sort of like whether it's column units. Or things that are standardized, you can actually export that so that when you need to dynamically generate something because sometimes with our view apps.

[00:05:08]
It doesn't make sense to do inline Styles over like keeping it in the soil block, but you can still keep up and have it stick with your design system without doing a lot of manual interpolation. So this is something that's really cool that I hopefully we'll see a lot more people using as they use CSS modules inside of their apps.

[00:05:28]
>> Question about browser support for CSS modules. Do you know if there's polyfills or support for IE 11?
>> So the question is around browser support for CSS modules, from what I understand at least, that everything that view is doing with CSS modules is done basically at compile time.

[00:05:50]
And so there's nothing that I'm aware of that should be limiting, because we saw the output is is still standard CSS classes. And so in that regard, there shouldn't be anything that's browser specific for these things because it's already been recompiled and renamed. So as long as you're following standards, the only browser things that would be applied to be depending on what properties you may be using inside of your style.

[00:06:11]
But it shouldn't have any direct correlation with the use of CSS modules as a whole is more of a build methodology from what I understand rather than like a browser thing. So the question here is around when we're v binding the class and using things like ternary statements to determine whether a class should exist.

[00:06:29]
Sort of there a better way to do this especially because the HTML can get clogged up over time. So I think the easiest way to do this is. I'm gonna jump over to VS code and let's just open, I'm just gonna open a view file and let's go ahead and check this out.

[00:06:45]
So the scenario being presented here is if we have again our h1 for example that says hello friend and masters. And here we have a v bind class that says, whether let's say, show element is true, then we'll have a class that's visible otherwise for example is hidden.

[00:07:07]
This is probably the simplest form of the ternary statement in a basically our element. So over time right this can get complicated as we need to chain different ones right it might be is visible is bold, position top, especially if we're using things like tailwind for example. There could be a lot of things were changing onto here.

[00:07:32]
And so generally speaking in my experience, the best way to approach this, once it's gotten the attorney's statement is basically getting fairly complex is to use a computer property in this case. And in this case, I might call this one, like title class names to be extremely explicit.

[00:07:49]
And then I would actually go ahead and do my calculations inside of here and so, whoops, that wasn't right see, copy. So then return this and then here, then we will just have titleClassNames. So you might be thinking that like with computed properties, you lose out on the ability to see what CSS classes are there.

[00:08:11]
But when it comes to, sort of deciding between computer properties versus leaving it in line, the reason why templates are useful is because they're declarative, and basically anyone can read it. And so, when we have a lot of complex logic regarding calculating what CSS classes we want, that's where it's going to get a little bit tricky.

[00:08:28]
And so, that's why readability is ultimately what it boils down to. So, if it's so complicated that it's already hard to figure out which goes where, It's better off just abstracting that directly to a computer properly.