转载自http://www.sitepoint.com/architecture-sass-project/
作者Hugo Giraudel
中文版
Remember when we used to do everything with nothing more than plain old CSS? All we had was a single CSS file, longer than a sleepless night. Yay! Thousands and thousands of lines — usually poorly written — of CSS where we were struggling to find the one value we had to change to fix some obscure and frustrating IE bug.
Well those days are behind us, folks. Dealing with CSS has become more interesting and more complicated. Probably the latter because of the former. And now that we have CSS preprocessors, responsive web design, progressive enhancement, graceful degradation, and all the other things cool kids talk about, CSS has become more powerful than ever.
“CSS has become more interesting and complicated.”— Me.
So because we have a lot to deal with, it is important that we stay organized. And we can probably all agree that it isn’t always easy to be. So I thought in this post I could help you to understand how you should think (rather than how you should do; I’ll leave that up to you).
Drawing Your Architecture
One of the main benefits of using a CSS preprocessor is having the ability to split your code into several files without impacting performance. Thanks to Sass’s @import
directive you can have as many files as you want in your developement environment and this will compile to a single file in production.
“Multiple files in dev, a single file in prod.”— Bruce Lee
Being organized starts with correctly splitting your CSS across several files and folders. As one of my teachers used to say “everything has its right place, every place has its right thing”. Well here is how I like to do it!
Folders are cool, use them
Folders are essential. At home, you don’t drop every sheet of paper into the same box. You probably have folders. One for the house/flat, one for the bank, one for bills, and so on.
When planning your CSS architecture, it is the exact same thing: you don’t just drop every Sass file into the same folder, you categorize them.
Here’s how we might organize our files:
sass/
|
|– base/
| |– _reset.scss # Reset/normalize
| |– _typography.scss # Typography rules
| ... # Etc…
|
|– components/
| |– _buttons.scss # Buttons
| |– _carousel.scss # Carousel
| |– _cover.scss # Cover
| |– _dropdown.scss # Dropdown
| |– _navigation.scss # Navigation
| ... # Etc…
|
|– helpers/
| |– _variables.scss # Sass Variables
| |– _functions.scss # Sass Functions
| |– _mixins.scss # Sass Mixins
| |– _helpers.scss # Class & placeholders helpers
| ... # Etc…
|
|– layout/
| |– _grid.scss # Grid system
| |– _header.scss # Header
| |– _footer.scss # Footer
| |– _sidebar.scss # Sidebar
| |– _forms.scss # Forms
| ... # Etc…
|
|– pages/
| |– _home.scss # Home specific styles
| |– _contact.scss # Contact specific styles
| ... # Etc…
|
|– themes/
| |– _theme.scss # Default theme
| |– _admin.scss # Admin theme
| ... # Etc…
|
|– vendors/
| |– _bootstrap.scss # Bootstrap
| |– _jquery-ui.scss # jQuery UI
| ... # Etc…
|
|
`– main.scss # primary Sass file
如你所见，在根目录下只有一个Sass文件： main.scss。其他所有文件都分布在合适的文件下下，并且带有下划线(_)前缀来告诉Sass它们是不应该被编译成css文件的局部.scss文件。事实上， 基础文件（此处即为main.scss）就是用来引入与合并这些文件的。
“One file to rule them all,One file to find them,One file to bring them all,And in the Sass way merge them.”— J.R.R. Tolkien
Let’s now look at each of the folders in our architecture.
Base
base/文件夹里放着我们项目的模板。在里面，可以找到reset样式（或者是Normalize.css）、文本排版相关的东西，根据项目的情况可能还有其他文件。
- _reset.scss或者_normalize.scss
- _typography.scss
Helpers
helpers/文件夹（有时也叫做utils/）包含所有我们项目中用到的Sass工具和帮助类。 Got a function? A mixin? Put it in there. This folder also contains a _variables.scss file (sometimes _config.scss) which holds all global variables for the project (for typography, color schemes, and so on).
- _variables.scss
- _mixins.scss
- _functions.scss
- _placeholders.scss (frequently named _helpers.scss)
Layout
The layout/ directory (sometimes called partials/) usually contains a number of files, each of them setting some styles for the main sections of the layout (header, footer, and so on). It also contains the_grid file which is the grid system used to build the layout.
- _grid.scss
- _header.scss
- _footer.scss
- _sidebar.scss
- _forms.scss
Having the navigation file (_navigation.scss) in this folder could make sense although I use to put it in components/ (see next section). I think it would be better in the layout/ folder but I’ll let you decide.
Components
For smaller components, there is the components/ folder (frequently called modules/). While layout/ is kind of macro (defining the global fireframe), components/
is more micro. It can contain all kinds of specific modules like a slider, a loader, a widget, or anything along those lines. There are usually a lot of files in components/ since your site is should be mostly composed of tiny modules.
- _media.scss
- _carousel.scss
- _thumbnails.scss
Pages
If you have page-specific styles, I think it’s cool to put them in a pages/ folder and in a file named after the page. For example, it’s not uncommon to have very specific styles for the home page, so you’d have a _home.scss file in pages/ dealing with this.
- _home.scss
- _contact.scss
根据你的部署过程，这些文件可以被单独调用以避免在最终的样式表中和其他文件合并。这取决于你。在我工作的地方，我们决定不把这些文件设成局部的，以方便仅在需要他们的页面进行引入。 For example, our home page has a very specific layout, compiling to about 200 lines of CSS. To prevent those rules from being loaded on every page, we include this file only on the home page.
Themes
If you are working on a large site with multiple themes like I do, having a themes/ folder can make sense. You can stuff all your theme/design related styles in there. This is definitely project-specific so be sure to include it only if you feel the need.
- _theme.scss
- _admin.scss
Vendors
And last but not least, you will probably have a vendors/ folder containing all the CSS files from external libraries and frameworks – Bootstrap, jQueryUI, Fancy, Carousel, Slider, jQueryPowered, and so on. Putting those aside in the same folder is a good way to tell “Hey, this is not from me, not my code, not my responsibility”.
Example:
- bootstrap.scss
- jquery-ui.scss
- select2.scss
On a side note, where I work we also have a vendors-extensions/ folder where we store files overriding some tiny bits from vendors. For example, we have a _bootstrap.scss file in there that we can use to change some components in Bootstrap. This is to avoid editing the vendor files themselves, which is generally not a good idea.
That’s pretty much it. This architecture is likely to vary according to the project but I’m sure you get the concept. On nesting folders in folders, I wouldn’t always advise against it but I don’t prefer that. I’ve found that in most cases, a single level of architecture is more than enough to keep things clean and organized without adding too much complexity. But if you think your project deserves a deeper structure, feel free to do so.
Pro tip: if you feel like your architecture isn’t obvious to anyone opening up the scss folder, you might consider adding a README.md file at the root level (side by side with main.scss) explaining everything.
Files are cool too!
A question I get asked frequently is “how many files is too many files?” and to that I’d reply: There are never too many files. Splitting your work across several files aims at helping you organizing your code. If you feel like something deserves to be divided into many files, feel free to go nuts! As Chris Coyier says in his Sass Style Guide:
“Break into as many small files as makes sense.”— Chris Coyier
Yet I’d advise against exploding a single component into several files unless you have very good reason to do so. Usually I tend to have one module per file — not more, not less — with a clean name like the name of the module it stands for. This way I can do a quick “go to” in Sublime text when I’m looking for something.
In Summary
All the suggestions in this article are based on my personal experience working as the sole front-end developer in the web-based branch of Crédit Agricole, a huge banking group in France. Your own circumstances and experiences might warrant a different approach.
If we could pick a Golden Rule for architecting a Sass project, it might be something as simple as: Pick something that makes sense. If you are working as a team on the front-end, make sure everyone feels comfortable with the chosen structure, else release documentation somewhere so that everybody can understand what’s going on.
Do you have any thoughts or suggestions on Sass architecture? We’d love to hear your comments.
“With great power comes great responsibility.”— Aquaman