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

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

Bootstrap-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.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 体系结构,原因是它适合我的思维方式。有必要提醒的是:嵌套越深,编译越久。

以上是 流行框架的 Sass 体系结构解析 的全部内容, 来源链接: utcz.com/z/264165.html

回到顶部