ruby-on-rails-4 - 导轨 : drawbacks of using Sass's @import instead of *=require

Question

我决定使用 Sass 的 @import而不是 Sprocket 的 *=require .

我有这个在 application.scss :

@import 'normalize';
@import 'font-awesome';
@import 'variables';

这在 blog.scss :

@import 'application';

这样我就有了单独的 Controller 的单独样式表(使我的代码更有条理)。

为了完成这项工作，我还添加了 stylesheet_link_tag params[:controller]到我的布局，然后添加 Rails.application.config.assets.precompile += %w( blog.css )行到我的/config/initializers/assets.rb 文件并重新启动服务器。

这种方法有什么缺点吗？ turbolinks 会更慢吗？

Answer 1

如果您有多个 Sass 文件，Rails Asset Pipeline 指南实际上建议使用 Sass 的 @import 而不是 Sprockets *=require。

以下是 Rails Asset Pipeline 指南中的一段话:

“如果你想使用多个 Sass 文件，你通常应该使用 Sass @import 规则而不是这些 Sprockets 指令。当使用 Sprockets 指令时，Sass 文件存在于它们自己的范围内，使得变量或 mixin 只在它们定义的文档中可用英寸(http://guides.rubyonrails.org/asset_pipeline.html)”

这也是在 sass-rails gem Github 页面 ( https://github.com/rails/sass-rails ) 上推荐的。这是该页面的引用:

“Sprockets 提供了一些放置在名为 require、require_tree 和 require_self 的注释中的指令。不要在你的 SASS/SCSS 文件中使用它们。它们非常原始，不能很好地处理 Sass 文件。相反，使用 Sass 的原生 @import sass-rails 定制的指令以与您的 Rails 项目的约定集成。”

这种方法没有任何明显的缺点，实际上有很多好处(包括但不一定限于):

主要优点来自于 SASS @import 创建了一个全局命名空间，而 Sprockets 指令则没有。

编译会在开发中加快一点，因为它不必在每次@import 的每个部分重新编译所有供应商 mixin。

使用 @import 全局命名空间会产生 Whorfian 效应，团队中的开发人员倾向于在他们应该(在变量文件中)而不是在更具体的文件中定义和重用他们的变量。例如，如果没有在全局变量文件 ( https://content.pivotal.io/blog/structure-your-sass-files-with-import ) 中定义 z-indexes 可能会成为一场噩梦。