До Rails 3.1 ці особливості додавалися сторонніми бібліотеками Ruby, таким як Jammit і Sprockets. Rails 3.1 інтегрований за замовчуванням зі Sprockets за допомогою Action Pack, який має залежність від гема sprockets.
Файлопровод за замовчуванням в Rails 3.1 включений. Він може бути відключений в config / application.rb. якщо помістити наступний рядок у визначенні класу програми:
Також файлопровод можна відключити при створенні нової програми, передавши опцію -skip-sprockets.
Слід використовувати значeния за замовчуванням для всіх нових додатків, якщо у вас немає особливих причин уникати файлопровода.
Основні особливості
Першою особливістю файлопровода є з'єднання ресурсів. Це важливо в середовищі production, оскільки може зменшити кількість запитів, необхідних браузеру для відображення сторінки. Браузери обмежені в кількості запитів, які вони можуть виконати паралельно, тому менше запитів може означати якнайшвидшу завантаження вашої програми.
Що за мітки і навіщо вони потрібні?
Мітки - це техніка, що здійснює залежність імені файлу від його вмісту. При зміні вмісту файлу, ім'я файлу також змінюється. Для статичного або нечасто оновлюваного вмісту це надає легкий спосіб сказати, що дві версії файлу ідентичні, навіть якщо вони на різних серверах, або мають різну дату розміщення.
Коли ім'я файлу унікально і засноване на його вмісті, заголовками HTTP можна встановити повсюдне кешування (в CDN. У провайдера, в мережевому обладнання або браузері), щоб у них була власна копія вмісту. Коли вміст змінюється, мітка теж зміниться. Це призведе до того, що віддалені клієнти зажадають нову копію вмісту. Ця техніка відома як cache busting.
Технікою, що використовується Rails для міток, є вставка хешу вмісту в ім'я, зазвичай в кінці. Наприклад, файл CSS global.css може бути перейменований за допомогою дайджесту MD5 його вмісту:
Це стратегія, прийнята файлопроводом Rails.
Колишньої стратегією Rails було додавання заснованої на дату рядка запиту до кожного ресурсу, приєднаному за допомогою вбудованого хелпера. У исходнике створений код виглядав так:
У стратегії, заснованої на рядку запиту, було кілька недоліків:
- Не всі кеші надійно кешуватися вміст, коли ім'я файлу відрізнялося тільки параметрами рядка запиту.
Steve Souders рекомендує. "... уникати рядки запитів для Кешована ресурсів". Він виявив, що в цьому випадку 5-20% запитом не будуть закешовану. Зокрема, рядки запиту зовсім не працюють з деякими мережами доставки контенту (CDN) для інвалідаціі кеша. - Файл може бути різним на різних вузлах в мультисерверного середовищах.
За замовчуванням, рядок запиту в Rails 2.x грунтується на часі зміни файлів. Коли ресурси розміщуються в кластер, немає ніякої гарантії, що тимчасова мітка буде однією і тією ж, в результаті будуть використані різні значення в залежності від того, який сервер буде обробляти запит. - Занадто багато припиненого кеша
При розміщенні статичних ресурсів з кожним новим релізом коду, mtime всіх цих файлів змінювалося, примушуючи всіх віддалених клієнтів отримувати їх знову, навіть якщо вміст цих ресурсів не змінювалося.
Мітки виправляють ці проблеми за допомогою уникнення рядків запиту і забезпечення, що ім'я файлу грунтується на його вмісті.
За замовчуванням мітки включені для production і відключені для всіх інших середовищ. Їх можна включити або відключити в конфігурації за допомогою опції config.assets.digest.