css - 页面特定的 Sass 文件和复制

Question

我真的很难在 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';

到目前为止一切顺利。所有这些文件都由 sprockets 组合成一个文档。然而，我随后想进一步模块化我的 Sass，使用特定于页面的文件或跨站点区域共享的文件。

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

resource.scss
gallery_resource.scss
badges.scss

也许还有来自 lib 的 css 文件:

gallery_lib.scss

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

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

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';

Answer 1

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

我个人的看法是，如果您很好地抽象了 CSS，则只需使用一个样式表，因为您一开始就没有很多特定于 View 的代码可以引入样式表。无论哪种方式，备选方案(根据页面需要随机加载模块，而您可能在上一页上已经做过同样的事情)听起来无论如何都无法解决该问题。此外，您对全新文件提出了更多请求。

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

您甚至可以创建一个结构来在两者之间共享元素，但这可能是必要的，也可能不是必要的。关键是无论您可能需要做什么，您都拥有很大的灵 active 和组织性。如果您愿意，同样的结构也可以用于 JS。这避免了重新加载模块和发出新请求的问题。

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

希望这对您有所帮助!