How do you like to organize your large SASS projects?
So many methodologies here, but I still haven't seen one that really feels like home to me. As a result every project I work on turns into an organizational experiment. Looking for more inspiration here.
Login
You'll need to login before you can leave that comment. Remember: Be nice or else. LoginRegister
New accounts will be able to leave comments immediately, but will gain full permissions over a week. Register now44 comments
Here's what I used to do:
- globals
- reset.sass
- mixins.sass
- vars.sass
- modules
- page.sass
- ...
- components
- radio.sass
- checkbox.sass
- ...
- posts
- modules
- components
- index.sass
- show.sass
- ...
- app.sass
- index.sass (imports)
However, since I started using React, I now keep styles alongside their components, but this used to work pretty well for me.
care to explain? Are you doing something like this?
- components
- component.js
- component.scss
Pretty much exactly that.
- Checkbox
- index.scss
- index.js
Then I can require the component:
import Checkbox from './components/Checkbox'
I also require the SASS file directly from the component using Webpack's SASS loader. Works a charm.
Had this question once before too:
http://zurb.com/tavern/questions/how-do-you-structure-your-sass-files
This is the structure I use on large projects with 60+ developers. It helps keep things in there proper place, and code is easy to find.
- Plugins
- plugin-dir
- burbon
- neat
- bitters
- Base
- base-dir
- typography
- variables
- mixins
- buttons
- forms
- Modules
- module-dir
- header
- footer
- article
- cards
- gallery
- Layouts
- layout-dir
- sidebar
- content
- lightbox
All these into their respective -dir file, then those into app.sass.
What goes into a sidebar? Literally anything that would appear in the sidebar? Do you ever find any situations where it could go in sidebar.scss but could also go in buttons.css or forms.scss?
Its a progression. Layouts handle the behavior and styles of the sidebar. So within the sidebar would be the padding/margin/layout things for the sidebar.
The buttons and forms would handle forms.
@Brandon, we've talked through a few different methodologies on the Stack Overflow Careers Product team. We considered BEM and kicked around Brad Frost's Atomic Design.
BEM class naming is a bit too verbose for us. We liked the simplicity of the approach though. We also liked the Atomic Design approach, but it felt too heavy-handed for our internal needs right now. Team members were unsure about where to put things.
In the end our approach is a modified BEM approach. Our folder structure is:
- base
- modules
- views
Class naming conventions aren't rocket science. We use this approach, which I've seen many others use:
.sampleElement {
...
.-childElement { ... }
&._modifyElement { ... }
}
Instead of appending classes to your HTML, have you thought about writing the SASS like this:
.sampleElement { ...
&-childElement { ... }
&_modifyElement { ... }
}
I'm not entirely sure you mean. If I have classes like so:
.sampleElement { ...
.-childElement { ... }
&._modifyElement { ... }
}
In HTML, we would apply them like so:
<div class="sampleElement">
<div class="-childElement"> ... </div>
</div>
<div class="sampleElement _modifyElement">
<div class="-childElement"> ... </div>
</div>
We do it this way so we're not writing out .sampleElement-childElement_modifyElement, which is just an extremely long class name.
I'm not sure having extremely long class names is very good indeed. It adds to the overall size of your CSS, in fine.
However, his suggestion was more to write descendent selectors using their parent class name as a prefix.
And then target them in your SCSS:
.foo { &-child { } }
I've been very satisfied with this method so far as it allow me to nest my SASS files comprehensively and keep my generated CSS as modular and reusable as possible.
Also, browsers scan class names from right to left... So there must be a gain in speed.
I also use this approach (LESS) when I write my CSS. The only drawback I find is that it doesn't allow for a good search if you need to search for example .foo-child.
I've solved this by adding "comments" to each "sub class". Like below. Not the prettiest solution but it works:
`.block {
// .block__element
&__element {}
// .block--modifier
&--modifier {}
}`
I use the architecture describe here http://sass-guidelin.es/#architecture
We use a system designed around Brad Frost's Pattern Library:
Basics
- Reset
- Mixins
- Variables
Atoms
- Borders
- Buttons
- Cards
- Colors
- Dropdowns
- Forms
- Helpers
- hr
- Icons
- Label
- Tables
- Typograpy
Molecules
- Flag
- Gallery
- Grid
- Media
- Well
Organisms
- Accordion
- Breadcrumbs
- Carousel
- Modal
- Nav
- Pagination
- Tooltips
- Wallpaper
Oh boy, I'm loving this.
It works well for my brain :). I like to think of the smallest and simplest elements and work my way up to the larger more complexed ones that require a lot of small elements. That way I can make sure we stay flexible at both a macro and micro level.
I'm in the middle of a new mobile build and I'm thinking about going "atomic" with the style/dir/organization and I'm pretty stoked about it.
I've spent the last hour collecting articles around Atomic design (which I feel I'm like 2 years behind on) because my initial reading on it kind of gets me really excited.
I feel like I've been doing it for years now, but only recently picked up that it had a name. I love designing in small, manageable pieces and then extrapolating up to complex doodads.
If you wouldn't mind sharing some of those articles, I'd be keen to take a look. I'm currently toying with BEM for class naming but haven't quite got a satisfactory Sass structure nailed yet. But I'm getting closer. I'd be keen on reading more about atomic design before I commit myself to the way I'm going currently!
Here are some of those articles/talks/resources:
Here's what we do at Trello: https://gist.github.com/bobbygrace/9e961e8982f42eb91b80#6-file-structure
Almost everything is a component. We avoid nesting and mixins and lots of complex preprocessor stuff. We have a BEM-like approach to class names and components, but it’s slightly different. .component.mod-modifer for modifiers. .is-state for state things. .js-action for JavaScript.
Is there any reason you use class names instead of data-attributes (regarding .js-action) for targeting elements? I ask because I used to use classes as well but recently switched to data-attributes, just to keep the class list purely style-specific.
It’s just convention. I could see data-attributes working just as well. The important thing is the separation of style and behavior concerns.
this thread terrifies me.
How come?
Looking through, I actually feel reasonably reassured most people are arriving at a roughly similar happy medium of breaking stuff down into 3 or 4 main folders and on a modular level not going too far (unless you go atomic which feels a little overkill).
If I were to take on a project from any of the posts here I wouldn't feel too lost in the stylesheets looking at most of the structures which I think is a good thing.
Similar, just different naming:
base
- _layout
- _breakpoints
- _colors
- _shadows
- _text
- _buttons
- _inputs
- _icons
- _variables
modules
- _cards
- _forms
- _actions
- _modals
- _notifications
- _comments
partials / components
- _header
- _account
- _lobby
- _gallery
- _pipeline
- _feed
and app.scss imports everything.
I wrote a detailed post about this recently, you might take something away from it.
It's a pretty large app with 40 devs and a couple million active users. Our approach is working great so far.
Nice write-up Colm!
Great post, Colm. Thanks for sharing!
┬
├─┬ sass
│ ├── base - base elements in SASS
│ ├── colors - where colors are declared
│ ├── components - ui components
│ ├── fonts - all things fonts
│ ├── scripts - Ruby scripted SASS functions
│ ├── settings - global sass variables
│ ├── utilities - object-oriented css
│ ├── vendor - third party CSS libraries
│ └── zindex - where z-indexes are declared
└─┬ svg - raw svg files
├── [censored] - [censored]
├── [censored] - [censored]
└── glyphs - SVGs (font source)
I'm so super curious to know what's in your [censored] directories.
Also, this is the first time I've seen someone else separate their z-index declarations. So helpful.
I do roughly what most people here are describing, except I like to structure my SASS files to more or less mirror my view templates (i.e., one stylesheet per template).
So under modules I might have...
- nav
- sidebar
- stage
- modals
- confirm dialog
- other dialog
etc
This will start an all out war with being as subjective of a topic.
The best way to think about it is, smalls bits and pieces.
I recently just found this, which can help guide you as you figure out your own ways of wanting to structure your stylesheets.
https://github.com/jasonreece/css-burrito
I didn’t ask what the “best” organization method is, only how individuals currently like to organize.
That is true. My apologizes for implying.
Externals (3rd party styles for anything I use like galleries and stuff) Layout (Higher level layout/page stuff/grid) Modules (Small components) Settings (Variables/Typography etc)
Anything more seems overkill to be honest.
ITCSS by Harry Roberts
Settings ( basic stuff and very general things like variable declarations for colors etc )
TOOLS ( mixins, functions etc )
GENERIC (CSS reset's etc)
BASE ( Headings base style, links base style, general declaration for body etc)
OBJECTS (Style you can use multiple times ( like Wrappers etc )
COMPONENTS ( Specific things, style for a particular part of HTML )
TRUMPS (useful classes you can use all the time).
I used to get caught up in specifying a bunch of directories, but now I keep it simple:
base/
------ _variables.scss
------ _functions.scss
------ _mixins.scss
------ _shared.scss
ui/
------ _typography.scss
------ _icons.scss
------ _header.scss
------ _footer.scss
------ _post.scss
...etc
vendor/
------ _normalize.scss
spaceBase was the inspiration for this.
I think another great question to ask is how are you importing separate SASS files and spitting them out?
Is everything getting compiled into one style.css and spit out on every page? Do you have one global.css and separate style.css sheets for different pages?
One single, unwieldy CSS file that is parsed using Gulp for autoprefixing and minimising. I never, or at least rarely, look at the generated CSS file.
Following simple-sassy-starter:
├── _shame.scss
├── screen.scss
├── partials
│ ├── _content.scss
│ ├── _forms.scss
│ ├── _layout.scss
│ └── _typography.scss
├── utility
│ ├── _mixins.scss
│ └── _variables.scss
└── vendor
└── _reset.scss
I've been experimenting with this a lot recently and this is what I've settled on (for now):
Directory Structure:
Master Stylsheet:
To summarize: master.scss imports all of the _all.scss files from each subdirectory, each of which imports the files from their respective subdirectories. _responsive.scss is on its own and always gets imported at the end to make sure I'm not affecting any core styling.