almost 9 years ago from Brandon Durham, Senior Interactive Designer / Developer with Hoefler & Co.
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.
Here's what I used to do:
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?
Pretty much exactly that.
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.
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.
All these into their respective -dir file, then those into app.sass.
@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:
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 {} }`
We use a system designed around Brad Frost's Pattern Library:
Basics
Atoms
Molecules
Organisms
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.
I use the architecture describe here http://sass-guidelin.es/#architecture
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!
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.
┬ ├─┬ 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.
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.
Similar, just different naming:
base
modules
partials / components
and app.scss imports everything.
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.
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 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?
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 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...
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.
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.
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.
Login to Comment
You'll need to log in before you can leave a comment.
LoginRegister Today
New accounts can leave comments immediately, and gain full permissions after one week.
Register now