3

我真的很难在 Rails 3.1 项目中构建 Sass 文件以避免大量重复......

我有以下结构，将 application.css.scss 作为我的主要布局的一部分导入：

application.css.scss
  - [*= require] main.css.scss
      - [@import] 'variables';
      - [@import]'bootstrap_overrides';
      - [@import]'bootstrap';
      - [@import]'base_elements';
      - [@import]'superstructure';
      - [@import]'modules';

到现在为止还挺好。所有这些文件都由 sprocket 组合成一个文档。但是，我想进一步模块化我的 Sass，使用特定于页面的文件或跨站点区域共享的文件。

所以在我的 GalleryResource#show 页面上，我需要使用额外的 Sass 文件：

resource.scss
gallery_resource.scss
badges.scss

也许是来自 lib 的 css 文件：

gallery_lib.scss

这些文件需要引用一些已经在 application.css 中导入的文件。他们需要使用 variables.css.scss 中定义的变量和 bootstrap 中定义的 mixins。所以我被迫在每个使用它们的文件中重新导入这些文件，导致大量重复。我可以为每个页面编写一个清单文件，但这是一个维护噩梦，仍然会导致重复和两个 css 文件；application.css 和 page_specific.css。

那么解决方案是什么？我是否需要放弃 application.css 并将其导入移动到每个特定于页面的文件中？因此，使用上面的示例，我最终会得到一个如下所示的清单文件：

gallery_resource_manifest.css.scss
      - [*= require] gallery_lib.css
      - [*= require] gallery_resource.css.scss
         - [@import] 'variables';
         - [@import]'bootstrap_overrides';
         - [@import]'bootstrap';
         - [@import]'base_elements';
         - [@import]'superstructure';
         - [@import]'modules';
         - [@import]'resource';
         - [@import]'gallery_resource';
         - [@import]'gallery';
         - [@import]'badges';
4

2 回答 2

9

我也尝试做你在组织风格时提到的同样的事情。Rails 通过不断为您生成基于控制器的样式表，几乎将您推向了这个方向。最后，我选择将所有内容添加到application.sass. 这种方法的主要优点是您只在页面加载时发出一个请求，并且最终不必重新导入用户在最后一页上请求的代码。

我个人的看法是，如果你很好地抽象了你的 CSS，你只需要使用一个样式表，因为你没有很多视图特定的代码可以首先引入到样式表中。无论哪种方式，替代方案（根据页面需求随机加载模块，而您可能在前一页上已经做了同样的事情）听起来无论如何都不能解决这个问题。另外，您正在对全新文件提出更多请求。

CSS 可能有点难以组织。这是我通常如何组织样式以及样式表目录的示例。此方法适用于单个命名空间（应用程序），或者如果需要，它可以分解为适用于多个命名空间（即管理员、应用程序）。

application.sass

// vendor ----------------------------------------------------------------------

// compass

@import "compass/reset"
@import "compass/css3/box-shadow"
@import "compass/css3/border-radius"
@import "compass/css3/box-sizing"
@import "compass/css3/opacity"
@import "compass/layout/sticky-footer"
@import "compass/utilities"

// grid

@import "susy"



// application -----------------------------------------------------------------


// base

// for mixins, variables and helpers to aid in building
// the application. no styling of actual elements should
// go in base.

@import "base/colors"
@import "base/fonts"
@import "base/mixins"
@import "base/grid"


// layout

// generic site styles. this includes site chrome styles
// such as the header, footer, flash messages, nav, as well
// as common patterns used around the site like forms, type,
// links, etc. the loose idea is that you could take these
// styles and create a similar "layout" but it wouldn't
// include contextual patterns like books, originals, etc.

@import "layout/buttons"
@import "layout/content"
@import "layout/header"
@import "layout/flash"
@import "layout/forms"
@import "layout/footer"
@import "layout/links"
@import "layout/tooltips"
@import "layout/typography"


// modules

// elements used on multiple pages that are loosely tied
// to our domain and data structure. examples are dependent
// on the needs of your site. as a general guideline, all 
// modules should be used on multiple pages. elements used 
// on a single page should be included in views.

@import "modules/articles"
@import "modules/buttons"
@import "modules/forms"
@import "modules/links"
@import "modules/pagination"
@import "modules/users"
@import "modules/stats"
@import "modules/some_other_domain_specific_styling_unique_to_your_site"


// views

// elements used on a single page. these styles are
// often needed to help put finishing touches on a
// page where modules didn't quite line up perfectly,
// or where a page has completely unique elements.
// these styles could often be abstracted to modules
// but lack a reason to do so. keeping them here helps
// explain their singular usage.

@import "views/welcome/index"
@import "views/settings/all"
@import "views/articles/show"
@import "views/users/show"

以这种方式组织您的样式有助于为每个文件创建一个单一的职责（看起来您也在尝试这样做）。我发现这让你的 CSS 更易于维护。此外，如果您需要添加媒体查询或使用给定模块定位特定浏览器，它为您提供了一个与上下文相关的地方，同时仍保持您的代码清晰和独立。

请注意，如果您只有一个命名空间，则将使用上面的示例。如果您有管理部分（或其他），您可以将所有这些目录/文件粘贴在“应用程序”目录中，并为“管理”创建类似的结构。这将为您留下以下结构app/stylesheets。

- admin
- application
- admin.sass
- application.sass

您甚至可以创建一个结构来在两者之间共享项目，但这可能是必要的，也可能不是必要的。关键是你有很大的灵活性和组织性来处理你可能需要做的任何事情。如果您愿意，同样的结构也可以用于 JS。这避免了重新加载模块和发出新请求的问题。

FWIW，我试图找到一种解决方案，只在每页中引入我需要的内容（你的问题），但最后我最终只是在整体上传递了更多位，同时增加了我的请求数量。YMMV。

希望这有助于您上路！

于 2012-10-19T23:14:51.277 回答
3

我通过从 rspec 获取提示并创建一个_sass_helper.sass包含我所有非直接样式导入（变量、mixins、占位符）的部分来解决这个问题，然后将其包含在每个文件的顶部。非代码位很重要，因为如果_sass_helper.sass包含任何样式，它们将被写入每个文件。

这有效地允许我为我的每个文件获得相同的“Sass 环境”，而无需任何代码重复。

我的树是这样组织的：

includes/
  _variables.sass
  _mixins.sass
  _extends.sass
posts/
  _post_partial_1.sass
  _post_partial_2.sass
application.sass
posts.sass
_sass_helper.sass

然后，像 posts.sass 这样的东西看起来像：

@import 'sass_helper'
@import 'posts/post_partial_1'
@import 'posts/post_partial_2'

.some.globally.shared.post
  styles: here

它工作得很好。post partials 不需要 sass 助手，所以我最终每个控制器都有一个主文件，各个功能的partials，并且到处都是相同的环境。

于 2012-10-19T23:35:43.667 回答