Статьи

Начало работы с конвейером активов, часть 2

К концу этой статьи вы должны хорошо понимать возможности конвейера активов в Rails, с которыми новичкам обычно сложно проводить время. Вы также получите хорошее представление о компиляции, снятии отпечатков пальцев, кэшировании, минимизации и сжатии. Трубопровод дает вам большой пробег и хорошее понимание того, почему так важно знать его особенности.

  • Звездочки?
  • Прекомпиляция Активов
  • Отпечаток MD5
  • Ссылки на активы
  • Стилизованные стили

Конвейер активов в Rails обрабатывается sprockets-rails . По умолчанию он включается при создании нового приложения Rails. Sprockets — это библиотека Ruby, которая помогает вам управлять активами JavaScript и CSS.

Кроме того, он заботится о компиляции, а также о предварительной обработке языков высокого уровня, таких как Sass, SCSS и CoffeeScript. Предварительная обработка просто означает, что ваши стили, HTML или JavaScript генерируются после написания кода на другом языке. Например, ваши таблицы стилей Sass предварительно скомпилированы в правильный CSS. Так как браузеры не могут понимать такие вещи, как CoffeeScript, мы должны предварительно обработать его.

Есть три драгоценных камня, которые играют жизненно важную роль во всем этом:

  • coffee-rails
  • uglifier
  • sass-rails

sass-rails позволяет вам писать свой вариант Sass для создания CSS, coffee-rails — более приятный синтаксис для написания JavaScript, а uglifier в свою очередь сжимает эти ресурсы. Кстати, sass-rails отвечает за сжатие CSS-файлов. Все три драгоценных камня будут добавлены в ваш Gemfile автоматически при создании нового приложения Rails. Если у вас есть причина не использовать Sprockets с Rails, вы можете пропустить его из командной строки при запуске приложения:

1
rails new appname —skip-sprockets

Эта команда предотвращает добавление вышеупомянутых гемов в ваш Gemfile и предоставляет вам другую версию файла config/application.rb . Теперь вам нужно настроить собственное решение для обработки ваших активов.

Когда вы предварительно обрабатываете что-то вроде CoffeeScript в допустимом JS или Sass в CSS, у вас также есть возможность еще немного обработать эти файлы. Минификация и сжатие — два больших. Минификация избавляет от вещей, которые не заботят браузер — например, пробелы и комментарии являются хорошими кандидатами. Sass также может иметь непосредственное отношение к минификации. Или вы просто используете Rails по умолчанию для компрессора YUI при работе с таблицами стилей. Помимо этого, Rails даже позволяет вам писать и настраивать свой собственный компрессор.

Следует отметить, что Sass имеет сжатую версию стилей вывода. Это на самом деле сбивает с толку, так как минимизирует ваши таблицы стилей. Сжатие — это другой процесс, значительно уменьшающий размер файла. Сжатие, или сжатие, предназначено для повторяющихся фрагментов кода и заменяет их указателями, которые занимают меньше места. Таким образом, чем более повторяющиеся файлы активов, тем больше они сжимаются и уменьшаются в размере.

Минификация довольно хорошая, но вы увидите самое большое уменьшение размера файла, когда будете использовать gzipping. Нередко файлы уменьшаются до 14% от их первоначального размера, если вы оба уменьшаете и сжимаете их. Когда вы думаете о загрузке тонны ресурсов по более медленным сетям, это может иметь огромное преимущество.

Для производства ваши активы должны быть скомпилированы в первую очередь. Файлы, которые вы помещаете в app/assets обычно необходимо предварительно обработать, прежде чем их можно будет обслуживать. О чем мы здесь говорим? Допустим, вы работали над новым приложением, которое работает на вашем локальном сервере. Ваши Sass файлы и ваш CoffeeScript со вкусом JavaScript работают волшебным образом из коробки. Круто, но что произойдет, если вы захотите перенести это на рабочий сервер? Такой сервер, отвечающий за доставку этого контента, возможно, гораздо большей аудитории, имеет несколько других требований, чем ваш локальный сервер.

По умолчанию Rails ищет файлы с именем application и пытается их предварительно скомпилировать. На этом этапе ресурсы компилируются из языков высокого уровня, таких как Sass, в CSS, и они объединяются — из нескольких файлов в меньшее количество пакетов. Наличие как можно меньшего количества файлов выгодно для производительности и скорости. Сжатие их размера до минимума также имеет огромное значение, особенно для больших приложений. Кроме того, файлы также кэшируются. Это означает, что вы загружаете новые активы только тогда, когда они были изменены с вашей стороны.

У вас есть два варианта, где вы хотите скомпилировать свои активы. Вы компилируете на своем производственном сервере или локально. Локальная компиляция означает, что вы сначала выполняете этот процесс на своем компьютере, а затем отправляете его в производство. Преимущества этого в том, что вам не нужен доступ для записи в файловую систему на производственном сервере, и если вы развертываете на нескольких серверах, вы можете выполнить этот процесс только один раз. Отсутствие необходимости в прекомпиляции ресурсов на сервере, если развернутые изменения не включают в себя изменения ресурсов, — это еще одно преимущество предварительной компиляции локально.

Прекомпиляция ресурсов — это одна из вещей, которую мы должны сделать, прежде чем отправлять им наши «чистые», скомпилированные CSS, HTML и JS. Серверы, вероятно, не должны знать о том, как работать с языками высокого уровня, такими как Sass, Slim и еще много чего. У них уже достаточно обязанностей. Чтобы это сработало, вы несете ответственность за то, чтобы на вашем компьютере было готово сжатие и минимизация драгоценных камней. Вы можете поместить эти скомпилированные активы в репозиторий Git — или в любой другой инструмент управления версиями, который вы предпочитаете — и развернуть только эти конечные активы в производство.

Rails предлагает вам задачу Rake, которая позаботится о прекомпиляции ресурсов. Такая задача представляет собой просто серию заранее определенных шагов, которые выполняются для достижения конкретной цели. Использование Rake build tool для таких вещей очень распространено в Ruby. Вы можете легко написать свои собственные задачи в Rake самостоятельно. Rails делает это очень легко. Из коробки Rails поставляется с каталогом lib/tasks котором вы можете удобно парковать свои задачи Rake. Дальнейшая настройка не требуется. Итак, когда вы бежите:

1
2
3
4
5
rake assets:precompile
 
or
 
bundle exec rake assets:precompile

Sprockets берет ресурсы, которые он может найти в своем пути поиска, и предварительно обрабатывает или компилирует их в public/assets . Вывод будет выглядеть примерно так:

1
2
3
4
5
6
7
your_rails_app/public/assets/application-454840c9c54adb8be789d8ca014fa0a02022a5dcd00523f2dd0469bc990ed0e6.js
 
your_rails_app/public/assets/application-454840c9c54adb8be789d8ca014fa0a02022a5dcd00523f2dd0469bc990ed0e6.js.gz
 
your_rails_app/public/assets/application-e80e8f2318043e8af94dddc2adad5a4f09739a8ebb323b3ab31cd71d45fd9113.css
 
your_rails_app/public/assets/application-e80e8f2318043e8af94dddc2adad5a4f09739a8ebb323b3ab31cd71d45fd9113.css.gz

Если вы хотите компилировать локально, рекомендуется изменить место, где Rails выводит ваши ресурсы. Если вы этого не сделаете, вам придется перекомпилировать ресурсы для разработки, потому что вы не увидите локальных изменений без них. Измененный URL-адрес будет использоваться Sprockets для обслуживания ваших активов в режиме разработки.

1
config.assets.prefix = «/dev-assets»

Для производства скомпилированные файлы по-прежнему будут помещаться в каталог /assets по умолчанию.

В итоге вы получите отдельные ресурсы, такие как файлы манифеста, такие как application.js и application.css . Таким образом, вам не нужно вручную связывать все свои ресурсы вручную в разметке и избегать необходимости загружать несколько файлов ресурсов вместо одного для каждой категории.

Длинный номер, который вы видите, который прикреплен, называется отпечатком пальца. Он используется для сравнения файлов и определения того, могло ли их содержимое измениться, прежде чем их снова нужно будет кэшировать. Вы также можете видеть, что вы получаете две версии одного и того же файла. Тот, что .gz расширение .gz, является gzip-версией ресурсов. gzip используется для сжатия и распаковки файлов, а также для удаления части жира, которую мы не хотим отправлять по проводам. Еще одно улучшение для увеличения скорости, в основном.

В случае, если вы чувствуете необходимость прекомпилировать свои ресурсы на производственном сервере, следующая команда ниже создаст ресурсы непосредственно на ваших серверах. Однако я добавляю это только для полноты картины. Я не уверен, что вам как новичку сейчас понадобится это.

1
RAILS_ENV=production bin/rails assets:precompile

Эти файлы манифеста, такие как application.css включают логику для импорта всех файлов по пути поиска. Rails сначала импортирует эти партиалы, а затем компилирует их в один авторитетный файл, который будет использовать браузер. Это просто по умолчанию, и вы можете изменить это, конечно.

Каждый файл манифеста имеет директивы, которые являются инструкциями, определяющими, какие файлы требуются для создания этих файлов манифеста. Там же определяется порядок, в котором они импортируются.

Окончательный результат содержит все содержимое всех файлов, к которым имеют доступ директивы. Sprockets загружает эти файлы, выполняет необходимую предварительную обработку и округляет все это, сжимая результат. Довольно чертовски полезно!

Для вашего файла манифеста CSS, app/assets/stylesheets/application.css , это выглядит следующим образом:

1
2
3
4
/* …
*= require_self
*= require_tree .
*/

Эквивалент JavaScript, app/assets/javascripts/application.js , выглядит примерно так:

1
2
3
4
// …
//= require jquery
//= require jquery_ujs
//= require_tree .

Как видно из этого примера, требование jQuery в первую очередь является обязательным, если вы полагаетесь на него в своем коде JavaScript.

По умолчанию Rails создает отпечаток для каждого имени файла во время процесса предварительной компиляции. В частности, Sprockets создает хеш MD5 из содержимого ваших файлов. Результирующая шестнадцатеричная строка из 32 символов, то есть дайджест, затем присоединяется к именам файлов ваших активов.

Это означает, что если содержимое ваших файлов изменится, ваши имена файлов, часть MD5, также изменится. Почему это называется дактилоскопией? Такие хэши имеют очень высокую вероятность быть уникальными и поэтому могут быть использованы для определения уникальности файла — как отпечатки пальцев.

1
navbar-908e25f4bf641868d8683022a5b62f54.css

Мы не говорим о рандомизированной шестнадцатеричной строке. Содержимое файлов проталкивается через математическую функцию, которая преобразует его в уникальную 32-символьную последовательность. Это означает, что вы получаете тот же хешированный результат, когда применяете функцию к одному и тому же контенту дважды — или как часто вам нравится.

С помощью этого умного механизма можно проверять изменения и обновлять только те файлы, которые приведут к другому хешу MD5. Для целей кэширования это золотой. Если ничего не изменилось, он кэшируется веб-браузером для будущих запросов. В этом контексте удаление кеша просто означает, что удаленные клиенты будут запрашивать новую копию файла, потому что отпечаток пальца изменился. Конечно, новый отпечаток будет создан и добавлен к имени вашего ресурса.

1
MD5(«The quick brown fox jumps over the lazy dog»)
1
9e107d9d372bb6826bd81d3542a419d6

Вы можете отключить снятие отпечатков пальцев как для производства, так и для разработки:

1
config.assets.digest = false
1
config.assets.digest = false

Давайте не будем забывать, почему хорошо иметь Asset Pipeline. Он направлен на то, чтобы вам было легко иметь дело с активами. Написание стилей и поведения для приложений становится все более нюансированным и сложным. С некоторыми инструментами работать стало веселее. Подготовка активов к производству и их обслуживание должны быть как минимум более простыми и сэкономить ваше время.

Немного автоматизации и соглашений по организации активов действительно приятно, потому что это облегчает вашу реальную работу. Asset Pipeline даже подслащивает сделку и завершает дело несколькими связями сахаристых активов. Это делает взрыв в работе с активами в вашем коде. Давайте рассмотрим несколько обычных подозреваемых, которые, надеюсь, еще больше повысят ваш уровень счастья:

  • javascript_include_tag
  • stylesheet_link_tag
  • image_tag

Начиная с его извлечения, Sprockets не изменил способ, которым вы можете связать свои активы; он все еще работает так же, как и раньше. Приведенные выше примеры являются вспомогательными методами, которые принимают имя ваших активов в качестве аргументов. Затем они сами выясняют имена расширений для коррелированных файлов. Эти вспомогательные методы не только создают необходимые теги для правильного HTML, но также заботятся о связывании с файлами ресурсов. Они, конечно, не обязательны, но все же приятно иметь и очень удобочитаемы. В вашей разметке будет меньше помех, если вы ими воспользуетесь.

1
2
3
4
5
<%= stylesheet_link_tag «some-stylesheet», media: «all» %>
 
<%= javascript_include_tag «some-js-file» %>
 
<%= image_tag «some-image.png» %>

В вашем глобальном файле макета Rails дает вам три из них из коробки.

1
2
3
4
5
<%= stylesheet_link_tag ‘application’, media: ‘all’, ‘data-turbolinks-track’ => true %>
 
<%= javascript_include_tag ‘application’, ‘data-turbolinks-track’ => true %>
 
<%= csrf_meta_tags %>

Это приводит к следующему выводу в отрендеренном HTML:

1
2
3
4
5
6
7
<link rel=»stylesheet» media=»all» href=»/assets/application.self-e80e8f2318043e8af94dddc2adad5a4f09739a8ebb323b3ab31cd71d45fd9113.css?body=1″ data-turbolinks-track=»true» />
 
<script src=»/assets/application.self-3b8dabdc891efe46b9a144b400ad69e37d7e5876bdc39dee783419a69d7ca819.js?body=1″ data-turbolinks-track=»true»></script>
 
<meta name=»csrf-param» content=»authenticity_token» />
 
<meta name=»csrf-token» content=»hwaD9ubZUD8tKOrHAA9wgccbxmnOW5mSl4VzU7S2UmPvTXv9fVJND25/YZOz84ntdpP0rhun6ShSEkkZrmcsbQ==» />

Давайте подробнее рассмотрим, как обрабатывать изображения.

К изображениям, помещенным в каталог public/assets/images можно получить доступ с помощью этого удобного метода — не нужно возиться с именами путей самостоятельно. Это хороший пример «соглашения о конфигурации» в работе.

1
<%= image_tag «some-image.png» %>

Это приведет к следующему:

1
<img src=»http://example.com/assets/some-image.png» alt=»Some image» />

Если активировано, Sprockets будет обслуживать такие файлы, если они найдены. Когда такой файл, как some-image.png , дактилоскопируется, например, some-image-9e107d9d372bb6826bd81d3542a419d6.png , он будет обрабатываться таким же образом.

Если вам нужны другие каталоги в public/assets/images или в app/assets/images для организации ваших изображений, возможно, что-то дополнительное для иконок или файлов svg , Rails не будет иметь проблем с их поиском. Вам просто нужно сначала добавить имя каталога:

1
2
3
<%= image_tag «icons/some-icon.png» %>
 
<%= image_tag «svgs/some.svg» %>

Понимаете, нет ракетостроения, и с другими помощниками активов обращаются так же.

Конвейер активов настроен для оценки кода ERB с самого начала. Все, что вам нужно сделать, это добавить расширение .erb к файлу, и все готово — Sprockets позаботится обо всем остальном. Когда вы генерируете контроллеры, он также создает представления, которые уже имеют расширение .erb . То же самое касается строительных лесов.

Но это работает и для таблиц стилей. Вы можете улучшить их, используя в них ERB. Вы просто создаете что-то вроде файлов example.css.erb . Хотя я не уверен, что это широко используемая техника. Это может быть очень удобно, но я, вероятно, буду осторожен при злоупотреблении этим, поскольку вы можете пойти очень далеко. Эти динамические файлы CSS, вероятно, не должны содержать слишком много логики. Это похоже на запах кода, но ущерб, кажется, сдерживается, если вы в основном полагаетесь на помощников ERB.

1
2
3
.some-class {
  background-image: url(<%= asset_path ‘some-image.png’ %>)
}

Это изображение будет найдено, если оно есть в одном из путей загрузки конвейера активов — обычно где-то в разделе app/assets/images . Круто то, что если этот файл уже обработан и снят с отпечатков пальцев, то Sprockets будет использовать путь public/assets и найдет его там. То же самое относится и к другим типам активов, конечно. Не забудьте использовать <%= %> , <% %> для интерполяции кода Ruby. Это не будет работать без них. Во время предварительной компиляции Sprockets будет интерполировать код, используемый в файлах CSS или Sass, и снова выводить простые файлы .css — конечно, с отпечатками пальцев или без них, в соответствии с вашими настройками.

Ниже приведены еще несколько вариантов, которые могут пригодиться для связи с различными категориями активов:

  • asset_path
  • asset_url
  • image_path
  • image_url
  • audio_path
  • audio_url
  • font_path
  • font_url
  • video_path
  • video_url

Разница между этими братьями и сестрами заключается в том, что версия _url дает вам полный путь, например http://example.com/assets/application.css , а версия _path преобразуется в относительный путь к _path , например /assets/application.css .

Когда вы используете самоцвет sass-rails , вы также можете использовать помощники path и url для ваших ресурсов. Они на самом деле не просто. Это так просто, как это:

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
.some-class {
  background-image: asset-path(«some-image.png»);
}
 
.some-class {
  background-image: asset-url(«some-image.png»);
}
 
.some-class {
  background-image: image-path(«some-image.png»);
}
 
.some-class {
  background-image: image-url(«some-image.png»);
}

Обратите внимание, что эти помощники используют дефис (-), а не подчеркивание (_).

image-path("some-image.png") переводится как "/assets/some-image.png" . image-url("some-image.png") расширится до url(/assets/some-image.png) который, в свою очередь, преобразуется в полный URL-адрес, например " http://www.example.com/assets/some-image.png" . То же самое касается asset-path , конечно.

Интересно, что этот драгоценный камень также предлагает свой собственный вид других помощников по активам из Rails. Это означает, что вам не нужно использовать файлы .erb и выполнять <%= %> интерполяцию в ваших таблицах стилей. Вы просто используете этих помощников из sass-rails , которые, на мой взгляд, кажутся более элегантными. Кроме того, менее вонючий код.

  • asset-path
  • asset-url
  • image-path
  • image-url
  • audio-path
  • audio-url
  • font-path
  • font-url
  • video-path
  • video-url

Эти вспомогательные методы точно знают, где найти ваши активы — если вы поместите их в обычный каталог, в основном это будет путь поиска. Разница между path и url том, что у вас есть относительные пути и один абсолютный путь. Быстрое напоминание: относительный путь — это путь к определенному месту назначения файла из некоторого другого местоположения файла. Абсолютные пути дают вам местоположение относительно корневого каталога.

Asset Pipeline был извлечен начиная с Rails 4 и больше не является основной функциональностью. Он включен по умолчанию, но Sprockets теперь отвечает за это. Вы можете пропустить его при запуске проекта.

Использование конвейера делает управление активами и компиляцию проще простого. Вам не нужно ничего настраивать, и вы можете сосредоточиться только на работе с этими ресурсами. Вишня на вершине в том, что вы получаете множество удобных методов удобства.

Ваши файлы для CSS, JS, CoffeeScript, Sass, Haml, Slim и т. Д. Аккуратно организованы в одном центральном месте в разделе app/assets . Sprockets отвечает за обслуживание файлов из этого каталога. Файлы там обычно требуют некоторой предварительной обработки, например, превращение файлов Sass в их эквивалентные файлы CSS.

К настоящему времени вы знаете большинство функций Asset Pipeline, которые новичкам, как правило, непросто повесить голову. Более важно, чем знать только его функциональность, теперь вы также знаете, почему. Вы должны иметь хорошее начальное представление о компиляции, снятии отпечатков пальцев, кэшировании, минимизации и сжатии. Я надеюсь, что вы по достоинству оцените, насколько этот конвейер для вас полезен, чтобы сделать жизнь вашего разработчика более удобной.