流行框架的 Sass 体系结构解析
为了应对项目开发中不断增长的复杂度和整体规模，开发者有必要使用恰当的逻辑，规划 Sass 文件的结构层次。遵循公认的编程规范，有助于开发者快速融入大型项目或团队的开发流程。下面就详细解析流行框架的结构层次。
Bootstrap 的目标是成为 Web 开发者的 UI 库，实现前端的快速开发，摆脱重复的基础性工作。其背后的逻辑是，在单一文件中聚合所有变量，而隐藏具体的混合宏等实现细节。它们的 Sass 体系结构就与此相似。每一个组件拥有独立的 Sass 文件，同时还存在一个 ./_variables.scss 文件——便于开发者控制项目中的所有变量。
Bootstrap 中 Sass 体系结构的独特之处，就在于它引用混合宏的方式。根目录下有一个 ./_mixins.scss 文件，该文件导入 mixins 文件夹的所有文件——该文件夹存放着每个混合宏的文件。举例来说，虽然是在 ./_buttons.scss 定义了按钮样式，但使用到的混合宏却是通过 ./_mixins.scss 导入的。如果继续追踪下去，会发现按钮的混合宏来自 mixins/_buttons.scss。Yo~Yo~~切克闹!
除了组件化的混合宏，该混合宏文件夹还包含了一些全局混合宏，比如 mixins/_border-radius.scss 和 mixins/_responsive-visibility.scss。虽然 Bootstrap 的混合宏并不复杂，但是这种体系结构更适用于那些混合宏非常复杂的项目，或者是混合宏需要独立为较小模块的项目。如果你想分离组件视觉风格和逻辑处理，那么使用这种体系结构也是合适的。简而言之，该体系结构适合于 Bootstrap 却不一定适合你。
目录结构如下：
bootstrap/
|– bootstrap.scss # Manifest file
|– _alerts.scss # Component file
|– _buttons.scss # Component file
|– _mixins.scss # Mixin file – imports all files from mixins folder
|– ... # Etc..
|– mixins/
| |– _alerts.scss # Alert mixin
| |– _buttons.scss # Button mixin
| |– ... # Etc..
Foundation 中的 Sass 体系结构思虑周到，非常适合用来自定义样式——这也是它的强大之处。在根目录下有一个 settings.scss，该文件允许开发者重写构建组件的所有变量。不过，每一个组件文件包含的变量都是针对该组件的。
此外，Foundation 在 functions.scss 文件中抽象出了项目中的函数。这种方式很棒，一方面这些函数是框架特有的，另一方面开发者也不用改写该文件。
边框圆角和过渡效果等全局混合宏都被引入到了 components/_global.scss。其逻辑结构如下：
- Import - global mixins
- Component specific variables (`$button-tny`, `$button-margin-bottom`)
- Component specific mixins
- Extends - (not the @extend but actual style definitions, where mixins are called)
所有特定组件的变量都会被定义为 !default，因此就可以在 _settings.scss 中重写这些变量了。如果你喜欢保持目录简洁，那么也可以直接修改 _settings.scss 中的变量。如果你喜欢折腾，完全可以修改特定组件的变量，此外修改组件的样式也很简单。
由于所有的组件是由混合宏和变量构建的，所以它具有最佳的灵活性。虽然有大量的网站在使用 Foundation，却不会千篇一律。
你可以借鉴 Foundation 的 Sass 体系结构，开发中小型站点。使用 Foundation，可以轻松使用任意组件，并且将所需要的变量、混合宏及其他扩展包含在同一文件中。
目录结构如下：
foundation/
|– foundation.scss # Manifest file
|– foundation
| |– _functions.scss # Library specific functions
| |– _settings.scss # Change variables for the entire project
| |– components
| | |– _buttons.scss # Component file (will import _globals.scss)
| | |– _globals.scss # Global mixins
| | |– _alerts.scss # Component file (will import _globals.scss)
Dale Sande，在他的演讲 “Clean out your Sass Junk-Drawer” 中，建议使用模块化的方法组织 Sass 文件。这对于企业级项目大有用处，因为此类项目往往具有大量高复杂度的模块。该方法还可以保留模块和所在文件夹的所有逻辑，这种逻辑允许子模块在作用域内继续扩展和重用样式。此外，如果你愿意将表现效果从 Sass 逻辑结构中分离，那么这也适合中小型项目。
使用 Dale Sande 的方法，最大的优势就是，可以轻易地为特定模块编写独立的样式。在项目内部，可以加载包含全局样式的基础样式，同时还可以加载针对特定模块的样式。这有助于移除代码中大量的膨化元素，改善性能和加载速度。
目录结构如下：
sass/
|– style.scss # Manifest
|– modules/
| |– registration/ # Sub Module
| | |– _extends.scss # Functional
| | |– _functions.scss # Functional
| | |– _mixin.scss # Functional
| | |– _module_registration.scss # Imports functional partials and contains presentational
| | |– _module_personalInfo.scss # Imports functional partials
Style Prototypes，出自 Sam Richard 之手，是一款优秀的工具，并包含了一系列在浏览器中使用 Sass 和 Compass 的设计规范。在此体系结构中，组件按逻辑分组为特定的文件夹，比如 base, components, layouts (SMACSS) 或者 atoms, molecules, components (atomic design)。
此外，每个组件拥有独自的部分： _variables.scss, _mixins.scss, _extends.scss 和清单文件 (_buttons.scss, _alerts.scss 等等)。
不过，这种方法有两个缺点：
- 编译时间——文件越多，编译所需的文件也就会越多
- 最初构建组件时，可能会在大量文件间进行切换。但是一旦完成，就可以轻而易举地维护和更改了。
这种方式的好处是，可以致力于单个模块的单一部分。它清晰地界定了设计一个组件所需的配置（变量）、功能（混合宏、扩展）和表现部分。全局配置则脱离组件-模块及的配置，独立设置。
在具有多个开发团队的大中型项目，这种分离有助于理清模块的层次结构。当需要时，也可以轻松常见特定模块的样式。
目录结构如下：
scss/
|– style.scss # Manifest
|– partials/
| |– base/
| | |– _content.scss
| | |– content
| | | |– _variables.scss # Component specific variables
| | | |– _extends.scss # Component specific extends
| | | |– _mixins.scss # Component specific mixins
| |– components/
| | |– _message.scss
| | |– message
| | | |– _variables.scss
| | | |– _extends.scss
| | | |– _mixins.scss
| |– global/
| | |– _variables.scss
| | |– _extends.scss
| | |– _mixins.scss
| | |– _functions.scss
| |– layouts/
| | |– _article.scss
| | |– article
| | | |– _variables.scss
| | | |– _extends.scss
| | | |– _mixins.scss
##SMACSS
个人认为，Hugo 基于 SMASS 的替代方法很棒，更多信息请参考 Sass architecture post。此外，也可以参考 SMACSS starter kit by Mina Markham。
##结论
本文中，我们分析了组织 Sass 文件的不同方式。至于使用哪种方式，有必要考虑一下复杂性、编译时间，以及个人喜好。
应用于团队开发时，事情就有点复杂了。你需要确保团队中的每个人，都可以接受你的方法，并愿意做出一些改变，以适应具体情况。
我最喜欢 Style Prototypes 体系结构，原因是它适合我的思维方式。有必要提醒的是：嵌套越深，编译越久。
##扩展阅读
本文根据@Vinay Raghu的《A Look at Different Sass Architectures》所译，整个译文带有我们自己的理解与思想，如果译得不好或有不对之处还请同行朋友指点。如需转载此译文，需注明英文出处：http://www.sitepoint.com/look-different-sass-architectures/。
南北
如需转载，烦请注明出处：https://www.fedev.cn/preprocessor/look-different-sass-architectures.htmlAir Jordan XIV High