SMACSS in our Workflow6:01 with Guil Hernandez
In this video, we'll learn how to use SMACSS to divide our project's code into smaller, more organized chunks.
Architecture is about creating a plan about how to structure things, and 0:00 that's what SMACSS is all about. 0:04 It's not a framework, so don't think of it as that. 0:06 It's more of a style guide for organizing our code. 0:09 So here, we're just going to cover the categorization of rules in SMACSS, but 0:12 if you wanna learn more about SMACSS, you can check out smacss.com. 0:17 So SMACSS is a perfect organization method when working with Sass. 0:22 Since we're able to use partials to split up 0:27 our code within the five categories we discussed earlier. 0:29 So far we've been doing a pretty nice job of keeping our code organized with partial 0:33 files, but let's see how we can break things down into smaller, 0:37 more organized chunks using SMACSS. 0:40 So, in our latest project workspace, notice how in our CSS directory, 0:43 I have created directories for most of the SMACSS categories. 0:49 I'll accept for themes since we won't be writing any themes here. 0:53 And we still have our main application.scss file to reference all 0:57 the other files in our directories. 1:02 More on that in just a bit. 1:04 So first, in our base directory, 1:05 we have the normalize.scss file containing all of our reset styles. 1:09 Then in the base.scss partial, we have the base styles for 1:15 a lot of our element selectors. 1:21 So for instance, 1:23 the body heading and paragraph rules we wrote in the previous stage. 1:24 Now, we shouldn't write out base rules as class or 1:29 ID selectors since they are defining the default styling for 1:32 how these elements will appear everywhere in our project. 1:36 So it's good to stick with the element selectors for these. 1:40 So right below, in the layout directory, is where 1:46 I've defined the layout styles for all the major components of our project. 1:49 This will often include partials for 1:55 the header, footer, content section, maybe sidebar or grid. 1:57 Again, this layout category's also pretty subjective. 2:02 Now, some developers don't use the layout category at all. 2:05 And instead refer to many of them as regular modules, or 2:08 components, which is totally fine. 2:12 So in our project, we're not defining layout rules for 2:14 many of the major layout components like headers or footers. 2:18 Instead, later on in this stage, we're gonna create a panel layout component that 2:23 can be used to layout some of those major components. 2:27 And everything else can be laid out with our grid, 2:30 which we're also going to build soon inside this layout directory. 2:33 So next, the modules category makes up the majority of our project styles. 2:37 By now, we know that anything that can sit inside a layout component and 2:43 can be reused anywhere on the page is considered a module. 2:47 And modules should have no knowledge of their parent container. 2:51 Now, we've already built several modules in the previous stage with BEM. 2:55 So I've split them up into partials. 2:59 So now every partial represents a standalone module. 3:02 This, again, keeps our sets organized and more manageable. 3:06 Now, one thing you might notice is this extends.scss file, and this is where 3:10 I like to write all the placeholder rules I'm extending in a particular directory. 3:15 So here in our modules extend, we have all the placeholders that 3:21 are extended in the nav items, headline, and button modules. 3:25 And this keeps our placeholders from being obscured, 3:30 which is important when working on teams. 3:33 So next, we don't have anything written in our state directory just yet. 3:38 In our state rules, we define if a module has a hidden, active, or 3:43 collapsed state, maybe an error or success state, and so forth. 3:47 Usually, java script plays a role in how these states are defined. 3:52 Now, we'll write a few state rules in an upcoming stage to define whether 3:56 an element is collapsed, visible, or hitting, depending on the page. 4:00 Finally, another file directory I like to use that's not really a part of SMACSS, 4:04 but useful nonetheless, is a utilities directory. 4:09 And this is where I keep my config file, all my functions, mixins, and 4:13 helper rules. 4:18 Now these could probably also go up here in our base directory as well, but 4:19 I like to keep them in a separate utilities directory. 4:24 Just for easier reference. 4:27 Again, it's all a matter of preference, so find what works for you and 4:29 stick with that. 4:32 You also might have noticed the index.scss partial in most directories. 4:33 Now, this is the same thing as what's commonly referred to as the manifest file. 4:40 And it's where we import all the other partials in the directories. 4:45 So, for example here, we're importing the config partial, 4:49 the functions partial, helpers, mixins, and so on. 4:52 And we have one of these index files in pretty much every directory. 4:56 So what this does is it makes our Sass a lot more manageable, 5:01 because we only need to import the single index reference from 5:05 each directory onto the main applications.scss file. 5:08 Now, you could also use a pretty neat method called globbing to 5:13 import all the project partials. 5:16 And in the Teacher's Note, 5:19 you'll see a link to Dale Sanz video on how to use globbing. 5:20 Finally, when importing each directory's index or 5:24 manifest file, it's important that we import the global dependencies first. 5:27 For example, the utilities and base rules. 5:32 Then, we import the layout, module, and state rules. 5:35 And if you have theme rules, import those last. 5:39 So as we can see, SMACSS is really about maintaining an organized and 5:42 logical structure to our code. 5:46 If you ever need a great starter toolkit for building a SMACSS project, 5:49 the wonderful Mina Markham has created on called Sassy Starter. 5:53 And you'll find the link to it in the Teacher's Notes 5:58
You need to sign up for Treehouse in order to download course files.Sign up