资产管道入门，第1部分

最新推荐文章于 2024-11-01 20:08:05 发布

cunjie3951

最新推荐文章于 2024-11-01 20:08:05 发布

阅读量149

点赞数

文章标签： python java 编程语言 html 人工智能

本文介绍Rails中的资产管道，探讨其核心功能，包括资产的串联、最小化和预处理。文章详细解释了Sprockets如何搜索资产，以及如何自定义搜索路径。同时，介绍了Sass、CoffeeScript、Slim和Haml等高级语言的使用，以及它们如何通过资产管道在Rails应用中编译。

摘要由CSDN通过智能技术生成

在有关Rails中的Asset Pipeline的新系列的第一篇文章中，我想讨论一些高层概念，这些概念对于完全掌握Asset Pipeline所提供的功能以及其幕后工作非常有用。它为您管理的主要内容是资产的串联，最小化和预处理。作为初学者，您需要尽早熟悉这些概念。

主题

资产管道？
组织
串联与压缩？
高级语言

资产管道？

资产管道对业务人员而言并非完全是新闻，但对于初学者而言，快速弄清楚可能有些棘手。开发人员不会在前端内容上花费大量时间，尤其是刚开始时。他们忙于处理许多与HTML，CSS或经常废弃的JS位无关的活动部件。

资产管道可以通过管理资产的串联，缩小和预处理来提供帮助，例如，以高级语言（如CoffeeScript或Sass）编写的资产。

这是Rails应用程序构建过程中的重要一步。 Asset Pipeline不仅可以提高质量和速度，还可以带来便利。必须设置自己的量身定制的构建工具可能会为您提供更多选择，以微调您的需求，但随之而来的开销对于初学者来说可能很耗时，甚至令人生畏。在这方面，我们可以谈论资产管道作为一种解决方案，该解决方案可以简化配置。

另一个不容小under的是组织。管道为放置资产提供了坚实的框架。当然，在较小的项目上，这似乎并不那么重要，但是较大的项目可能无法从错误的方向上轻松恢复，例如这样的主题。这可能不是世界上最常见的示例，但可以想象一下像Facebook或Twitter这样的项目，其CSS和JS资产组织不善。很难想象这会带来麻烦，而且必须在这样的基础上工作和建设的人们不会轻易度过工作。

与Rails中的许多事情一样，有一种常规的方法来处理资产。这使得加入新人变得更加容易，并且避免让开发人员和设计师过于着迷于将自己的面团带到聚会上。

当您加入新团队时，您希望能够快速起步并踏上第一步。需要弄清楚其他人如何组织资产的特殊技巧并不能完全帮到您。在极端情况下，这甚至可能被认为是浪费的，并且可能不必要地浪费金钱。但是，让我们在这里不要太戏剧化。

因此，本文适用于您中的初学者，即使您不希望将来会过多地处理标记或前端事务，我也建议您立即查看管道并牢牢掌握该主题。。这是Rails中必不可少的方面，并不是一件大事。另外，如果您有一些彼此不冲突的共同点，那么您的团队成员，尤其是在这些目录中花费了一半时间的设计师，将会在您的咖啡中放些有趣的东西。

组织

您有三种放置资产的选择。这些划分更合乎逻辑。它们不代表任何技术限制。您可以将资产放在其中任何一个中，并看到相同的结果。但是对于更聪明的组织，您应该有充分的理由将内容放置在适当的位置。

app/assets

app/assets/
├── images
├── javascripts
│   └── application.js
└── stylesheets
    └── application.css

app/assets文件夹用于特定于此应用程序的资产-为特定项目量身定制的图像，JS和CSS文件。

lib/assets

lib/assets/

另一方面， lib/assets文件夹是您自己的代码的宿主，您可以在项目之间重复使用这些代码，您自己可能已经提取并想要从一个项目转移到下一个项目，尤其是您所拥有的资产可以在应用程序之间共享。

vendor/assets

vendor/assets/
├── javascripts
└── stylesheets

vendor/assets是向外的又一步。这是您从其他外部资源（第三方的插件和框架）重用的资产的存放地。

这是Sprockets将在其中寻找资产的三个位置。在上述目录中，您应该将资产放置在/images ， /stylesheets和/javascripts文件夹中。但是，这更多的是常规的事情。 */assets文件夹中的所有资产都将被遍历。您还可以根据需要添加子目录。无论如何，Rails都不会抱怨并对其文件进行预编译。

有一种简单的方法可以查看资产管道的搜索路径。使用rails console启动Rails控制台时，可以使用以下命令进行检查：

终奌站

Rails.application.config.assets.paths

您将得到的返回结果是一个数组，其中包含Sprockets可用并找到的资产的所有目录，也就是搜索路径。

=> ["/Users/example-user/projects/test-app/app/assets/images", "/Users/example-user/projects/test-app/app/assets/javascripts", "/Users/example-user/projects/test-app/app/assets/stylesheets", "/Users/example-user/projects/test-app/vendor/assets/javascripts", "/Users/example-user/projects/test-app/vendor/assets/stylesheets", "/usr/local/lib/ruby/gems/2.3.0/gems/turbolinks-2.5.3/lib/assets/javascripts", "/usr/local/lib/ruby/gems/2.3.0/gems/jquery-rails-4.1.1/vendor/assets/javascripts", "/usr/local/lib/ruby/gems/2.3.0/gems/coffee-rails-4.1.1/lib/assets/javascripts"]

所有这些的好处很容易错过。这是约定的方面。这意味着开发人员以及设计人员实际上都可以对在哪里查找文件以及在哪里放置文件有一定的期望。那可以节省大量的（特朗普声音）时间。当新来的人加入一个项目时，他们有一个很好的主意，即如何立即浏览一个项目。

这不仅方便，而且还可以始终防止出现可疑的想法或重新发明轮子。是的，配置约定有时听起来有些无聊，但仍然是功能强大的东西。它使我们专注于重要的事情：工作本身和良好的团队协作。

但是，提到的资产路径并不是一成不变的。您也可以添加自定义路径。打开config/application.rb并添加您想被Rails识别的自定义路径。让我们看一下如何添加一个custom_folder 。

config.application.rb

module TestApp
  class Application < Rails::Application
    config.assets.paths << Rails.root.join("custom_folder")
  end
end

现在再次检查搜索路径时，您会发现自定义文件夹是资产管道搜索路径的一部分。顺便说一下，它现在将是放置在数组中的最后一个对象：

终奌站

Rails.application.config.assets.paths

输出量

["/Users/example-user/projects/test-app/app/assets/images", "/Users/example-user/projects/test-app/app/assets/javascripts", "/Users/example-user/projects/test-app/app/assets/stylesheets", "/Users/example-user/projects/test-app/vendor/assets/javascripts", "/Users/example-user/projects/test-app/vendor/assets/stylesheets", "/usr/local/lib/ruby/gems/2.3.0/gems/turbolinks-2.5.3/lib/assets/javascripts", "/usr/local/lib/ruby/gems/2.3.0/gems/jquery-rails-4.1.1/vendor/assets/javascripts", "/usr/local/lib/ruby/gems/2.3.0/gems/coffee-rails-4.1.1/lib/assets/javascripts", #<Pathname:/Users/example-user/projects/test-app/custom_folder>]

串联与压缩？

为什么我们需要这些东西？长话短说，您希望您的应用程序加载速度更快。期！欢迎任何有帮助的方法。当然，您可以在不为此进行优化的情况下逃脱现实，但是它具有太多的优势，人们根本无法忽略。压缩文件大小并将多个资产文件串联为一个由客户端（如浏览器）下载的“主”文件也没有太多工作。无论如何，它主要由管道处理。

减少渲染页面的请求数量对于加快处理速度非常有效。在浏览器完成获取资产之前，可能没有10、20、50或任何数量的请求，而是每个CSS和JS资产可能只有一个。今天，这是一件令人愉快的事情，但在某些时候，这是一个改变游戏规则的人。 Web开发中的这些改进不应忽略，因为我们以毫秒为单位进行处理。

许多请求可能会大大增加。毕竟，对于成功的项目而言，用户体验才是最重要的。让用户只等一小会儿就可以看到页面上呈现的内容，这可能是一个大问题。耐心不是我们的用户所期望的。

缩小很酷，因为它可以消除文件中不必要的内容-基本上是空格和注释。这些压缩文件的制作并非出于人类可读性的考虑。它们仅用于机器消耗。尽管这些文件仍然是所有有效CSS和JS代码，但最终看起来有些晦涩难懂，而且很难阅读-只是没有任何多余的空格使它对于人类来说是易读易懂的。

但是，JS压缩涉及更多。 Web浏览器不需要这种格式。这样我们就可以优化这些资产。本部分的要点是，减少请求数量和最小化文件大小可以加快处理速度，这应该由您来解决。 Rails无需任何其他设置即可立即为您提供此功能。

高级语言

您可能已经听说过它们，但是作为一个初学者，您可能不了解为什么要学习另一种语言-特别是如果您仍在忙于编写经典HTML和CSS时。创建这些语言是为了解决开发人员想要消除的缺点。他们主要解决开发人员不想每天处理的问题。我猜是经典的懒惰驱动开发。

“高级语言”听起来比想象中的还要花哨，尽管它们很老实。我们正在谈论Sass，CoffeeScript，Haml，Slim，Jade等。这些语言使我们可以使用（主要是）用户友好的语法进行编写，从而可以更方便，更高效地使用。所有它们都需要在构建过程中进行预编译。

我之所以提及这一点，是因为这可能在幕后发生而您没有注意到。这意味着在部署它们并可以由浏览器呈现之前，需要将这些资产转换为CSS，HTML和JS。

萨斯

Sass代表“语法上很棒的样式表”，并且比纯CSS更有效。它使我们能够编写更智能的样式表，其中包含一些编程工具。在这里，我们到底在说什么？您可以声明变量，嵌套规则，编写函数，创建混入文件，轻松导入局部变量以及程序员希望在使用样式时获得的许多其他内容。

到目前为止，它已经发展成为一种非常丰富的工具，并且非常适合组织样式表-对于大型项目，我什至认为这是必不可少的。这些天来，我不确定我是否会远离没有使用诸如Sass之类的工具的大型应用程序-或在这方面必须提供的任何非Ruby中心框架。

对于当前的担忧，您需要了解Sass的两种语法版本。 Sassy CSS版本（又名SCSS）是使用更广泛的版本。它更接近纯CSS，但提供了所有花哨的扩展，开发人员和设计师都喜欢使用样式表。它使用.scss文件扩展名，看起来像这样：

SCSS

#main p {
  color: #00ff00;
  width: 97%;
  .redbox {
    background-color: #ff0000;
    color: #000000;
  }
}

从外观上看，它与CSS没什么不同，这就是为什么它是最受欢迎的选择的原因，尤其是在我认为的设计师中。嵌套方面是SCSS（通常是Sass）真正很方便的方面之一。这是创建可读样式的有效策略，但也减少了重复声明的数量。

SCSS

#main {
  color: blue;
  font-size: 0.3em;
  a {
    font: {
      weight: bold;
      family: serif;
    }
    &:hover {
      background-color: #eee;
    }
  }
}

将上面的示例与相应CSS版本进行比较。通过嵌套简化这些样式看起来不错，不是吗？

CSS

#main {
  color: blue;
  font-size: 0.3em;
}

#main a {
  font-weight: bold;
  font-family: serif;
}

#main a:hover {
  background-color: #eee;
}

缩进的Sass语法具有.sass文件扩展名。这使您避免处理懒惰的开发人员喜欢避免的所有这些愚蠢的花括号和分号。

它是如何做到的？没有括号，Sass使用缩进（本质上是空格）来分隔其属性。很漂亮，看起来也很酷。为了看到不同之处，我将同时向您展示两个版本。

.sass

#main
  color: blue
  font-size: 0.3em
  a
    font:
      weight: bold
      family: serif
    &:hover
      background-color: #eee

.scss

#main {
  color: blue;
  font-size: 0.3em;
  a {
    font: {
      weight: bold;
      family: serif;
    }
    &:hover {
      background-color: #eee;
    }
  }
}

非常漂亮和紧凑，是吗？但是，这两个版本都需要进行处理，然后才能转换成浏览器可以理解的有效CSS。资产管道为您解决了这一问题。如果您使用Sass之类的浏览器访问浏览器，它们将不知道发生了什么。

我个人更喜欢缩进语法。这种对空格敏感的Sass语法不如SCSS语法流行，这可能不是使其成为您个人项目以外的其他项目的理想选择。最好选择团队中最受欢迎的选择，尤其是在涉及设计师的情况下。与花了数年时间来驯服所有花括号和分号的人一起使空白时髦似乎是一个坏主意。

两种版本都具有相同的编程技巧。他们擅长使写作风格的过程更加愉悦和有效。对我们来说幸运的是，Rails和Asset Pipeline使得使用它们中的任何一个都变得如此容易-相当开箱即用。

Slim＆Haml

对于使用Slim和Haml之类的好处，可以提出类似的观点。它们对于创建更紧凑的标记非常方便。它将被编译成有效HTML，但是处理的文件大大减少了。

您可以省去编写结束标签的麻烦，并为标签名称等使用凉爽的缩写。这些较短的标记爆发更易于浏览和阅读。就个人而言，我从不曾是Haml的忠实拥护者，但是Slim不仅花哨且方便，而且非常聪明。对于喜欢缩进Sass语法的人，我绝对会建议您使用它。让我们快速看一下：

瘦

#content
  .left.column
    h2 Welcome to our site!
    p= print_information
  .right.column
    = render :partial => "sidebar"

哈姆

#content
  .left.column
    %h2 Welcome to our site!
    %p= print_information
  .right.column
    = render :partial => "sidebar"

两者都会在Rails中产生以下ERB增强HTML：

<div id="content">
  <div class="left column">
    <h2>Welcome to our site!</h2>
    <p>
      <%= print_information %>
    </p>
  </div>
  <div class="right column">
    <%= render :partial => "sidebar" %>
  </div>
</div>

从表面上看，差异并不大，但是我从来不知道为什么Haml希望我写所有这些额外的%来添加标签。 Slim找到了解决这些问题的解决方案，因此我向团队致敬！虽然不是很大的痛苦，但是却很烦人。其他差异在表面之下，不在今天的讨论范围之内。只是想激发您的胃口。

如您所见，两个预处理器都大大减少了您需要编写的数量。是的，您需要学习另一种语言，一开始它听起来有点怪异。同时，我觉得消除这些杂乱是完全值得的。此外，一旦您知道如何编写带有ERB风格HTML，您就可以相当快地使用这些预处理器中的任何一个。没有火箭科学，顺便说一句，萨斯也是如此。

如果您有兴趣，可以在Rails中使用两个方便的工具。帮自己一个忙，当您厌倦了编写所有这些烦人的开始和结束标签时，请检查一下。

gem "slim-rails"

gem "haml-rails"

CoffeeScript

CoffeeScript是和其他语言一样的编程语言，但是它具有Ruby风格，可用来编写JavaScript。通过预处理，它可以编译成浏览器可以处理的简单的旧JavaScript。使用CoffeeScript的简短论点是，它有助于克服JS带来的一些缺点。该文档说，其目的是公开“以一种简单的方式编写JavaScript的好部分”。很公平！让我们快速看一个简短的示例，看看我们正在处理什么：

JavaScript

$( document ).ready(function(){
  var $on = 'section';
  $($on).css({
    'background':'none',
    'border':'none',
    'box-shadow':'none'
  });
});

在CoffeeScript中，这个小伙子看起来像这样：

CoffeeScript

$(document).ready ->
  $on = 'section'
  $($on).css
    'background': 'none'
    'border': 'none'
    'box-shadow': 'none'
  return

没有所有的curl和分号就读得更好一点，不是吗？ CoffeeScript尝试处理JavaScript中的一些烦人的部分，使您键入的内容更少，使代码更具可读性，提供更友好的语法，并且在编写类时更愉快。定义类在一段时间内是一大优势，特别是对于那些来自Ruby的人，他们不喜欢纯JavaScript。 CoffeeScript采用了与Ruby类似的方法，并为您提供了不错的语法糖。类看起来像这样，例如：

类

class Agent
  constructor: (@firstName, @lastName) ->

  name: ->
    "#{@first_name} #{@last_name}"

  introduction: (name) ->
    "My name is #{@last_name},  #{name}"

这种语言在Ruby领域相当流行了一段时间。我不确定这些天的采用率如何，但是CoffeeScript是Rails中的默认JS风格。借助ES6，JavaScript现在还支持类-一个可能不使用CoffeeScript而是使用纯JS的主要原因。我认为CoffeeScript仍然读起来更好，但是如今使用ES6已经解决了许多使用起来不太美观的原因。我认为这仍然是一个很好的理由，但这不是您来这里的目的。我只是想给您另一个开胃菜，并提供一些有关为何资产管道允许您直接使用CoffeeScript的背景信息。