流行框架的 Sass 体系结构解析

特别声明:小站对部分原创文章已开启付费阅读,并开通年费VIP通道,年费价格为 ¥365.00元。如果您喜欢小站的内容,可以点击开通会员进行全站阅读。如果您对付费阅读有任何建议或想法,欢迎发送邮件至: airenliao@gmail.com!(^_^)

为了应对项目开发中不断增长的复杂度和整体规模,开发者有必要使用恰当的逻辑,规划 Sass 文件的结构层次。遵循公认的编程规范,有助于开发者快速融入大型项目或团队的开发流程。下面就详细解析流行框架的结构层次。

Bootstrap-sass

Bootstrap 的目标是成为 Web 开发者的 UI 库,实现前端的快速开发,摆脱重复的基础性工作。其背后的逻辑是,在单一文件中聚合所有变量,而隐藏具体的混合宏等实现细节。它们的 Sass 体系结构就与此相似。每一个组件拥有独立的 Sass 文件,同时还存在一个 ./_variables.scss 文件——便于开发者控制项目中的所有变量。

Bootstrap 中 Sass 体系结构的独特之处,就在于它引用混合宏的方式。根目录下有一个 ./_mixins.scss 文件,该文件导入 mixins 文件夹的所有文件——该文件夹存放着每个混合宏的文件。举例来说,虽然是在 ./_buttons.scss 定义了按钮样式,但使用到的混合宏却是通过 ./_mixins.scss 导入的。如果继续追踪下去,会发现按钮的混合宏来自 mixins/_buttons.scssYo~Yo~~切克闹!

除了组件化的混合宏,该混合宏文件夹还包含了一些全局混合宏,比如 mixins/_border-radius.scssmixins/_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..

Zurb Foundation

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 的体系结构

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

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/

南北

在校学生,本科计算机专业。狂热地想当一名作家,为色彩和图形营造的视觉张力折服,喜欢调教各类JS库,钟爱CSS,希望未来加入一个社交性质的公司,内心极度肯定“情感”在社交中的决定性地位,立志于此改变社交关系的快速迭代。

如需转载,烦请注明出处:http://www.w3cplus.com/preprocessor/look-different-sass-architectures.htmlAir Jordan XIV High

如需转载,烦请注明出处:https://www.w3cplus.com/preprocessor/look-different-sass-architectures.html

如果文章中有不对之处,烦请各位大神拍正。如果你觉得这篇文章对你有所帮助,打个赏,让我有更大的动力去创作。(^_^)。看完了?还不过瘾?点击向作者提问!

赏杯咖啡,鼓励他创作更多优质内容!
返回顶部