Preview
Video Player
00:00
00:00
SMACSS in our Workflow
6:01In 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