Co To jest rurociąg aktywów

BY admin
|

cele

  1. poznaj 4 Główne cechy rurociągu aktywów.
  2. Zidentyfikuj ścieżki zasobów
  3. dowiedz się, jak manifesty zasobów zapewniają połączenie CSS i JS.
  4. używaj języków przetwarzania wstępnego, takich jak SASS lub CoffeeScript
  5. Definiuj Odcisk Palca zasobów

zarys

przez długi czas traktowaliśmy JavaScript i CSS jako refleksję przy tworzeniu aplikacji internetowych. Cały nasz kod zasobów — obrazy, arkusze stylów i skrypty JavaScript-był przechowywany w ogromnym folderze o nazwie public i obsługiwany poza kontekstem naszej aplikacji Rails. W miarę rozwoju sieci, nie miało to już sensu.

potok zasobów jest odpowiedzią Rails na zarządzanie arkuszami stylów, skryptami JavaScript i obrazami.

ścieżki zasobów

wiele plików zajmuje się tworzeniem aplikacji internetowych. Same pliki CSS i JavaScript mogą być trudne do zorganizowania. Jakie foldery tworzymy? Które Pliki gdzie? Rurociąg aktywów stanowi odpowiedź na ten problem. Musimy zachować porządek w naszej aplikacji, ale zachowując oddzielne pliki i foldery dla każdej koncepcji lub jednostki kodu, mamy 2 problemy.

  1. skąd Rails wie, gdzie rzeczy są? Czy plik kalendarza JS Znajduje się w app/assets/javascripts/calendar.js czy vendor/javascripts/calendar.js?
  2. nie chcemy serwować KAŻDEGO pliku osobno, ponieważ spowoduje to, że nasza strona ładuje się bardzo wolno. Ma sens utrzymywanie oddzielnych małych plików dla czytelności i organizacji, ale w przypadku przeglądarki wolelibyśmy rozbić wszystkie te małe pliki razem i załadować 1 plik JS i 1 plik CSS. Proces ten nazywany jest konkatenacją.

porozmawiajmy o naszym pierwszym problemie: skąd Rails wie, gdzie szukać? Rurociąg zasobów ma koncepcję zwaną ścieżkami zasobów do obsługi tego. Podobnie jak w BASH, gdzie mamy zmienną środowiskową PATH, która jest kombinacją ścieżek folderów, ścieżka zasobów jest kombinacją ścieżek folderów, w których Rails mogą szukać zasobów. Spójrzmy na przykład, jak skonfigurowana jest nasza ścieżka zasobów.

Rails.application.config.assets.paths =>

jeśli umieścimy zasób w którymkolwiek z tych folderów, możemy uzyskać do nich dostęp za pomocą adresu URL „/assets ” w naszej aplikacji. Jeśli masz dodatkowe foldery do przeszukiwania w systemie Rails, możesz je dodać do ścieżki zasobu. Odbywa się to w pliku config/initializers/assets.rb.

Rails.application.config.assets.paths << "New Path"

możemy umieścić zasoby w dowolnym miejscu, skonfigurować naszą ścieżkę zasobów i uzyskać do nich dostęp za pomocą jednego adresu URL „/assets”.

manifesty i Konkatenacje

teraz, gdy możemy umieścić pliki w dowolnym miejscu, jak sprawić, by znalazły się na naszych stronach internetowych? Potok zasobów używa pliku manifestu, aby powiedzieć Rails, co mają załadować. Ten plik manifest jest centralną lokalizacją, w której możemy wyświetlić listę wszystkich plików CSS i JS, których potrzebuje nasza aplikacja. Nie jest to funkcja JS lub CSS, ale raczej potok zasobów. Oto przykład jak wygląda nasz plik manifestu JS:

plik: app/assets/javascripts / application.js

//= require jquery//= require calendar

po dołączeniu pliku manifestu do Układu z javascript_include_tag potok zasobów będzie szukał wszystkich plików wymienionych w ścieżce zasobu. Zwróć uwagę, jak potrzebujemy kalendarza. Ten plik znajduje się w app/assets/javascripts/calendar.js, ale podaliśmy tylko nazwę, a nie pełną ścieżkę. Potok zasobów przeszukuje wszystkie skonfigurowane ścieżki w poszukiwaniu pliku o podanej przez nas nazwie.

teraz, gdy rozwiązaliśmy kwestię wykrywalności, porozmawiajmy o konkatenacji. Jak mówiliśmy wcześniej, nie chcemy ładować naszych plików w przeglądarce jeden po drugim. Lepiej jest wykonać jedno pobieranie niż kilka małych pobrań z naszej przeglądarki. Pliki manifestu, które konfigurujemy w Rails, automatycznie połączą wymienione w nich pliki w jeden plik w produkcji. Może to nie być najlepsza opcja, gdy rozwijamy naszą aplikację, ponieważ może to utrudnić debugowanie. Jednak Rails faktycznie będzie obsługiwał każdy plik osobno, gdy będziemy działać w trybie deweloperskim. Nie musisz nic robić.

wreszcie dyrektywy sprocket, które zasilają nasze manifesty aktywów, zostaną szczegółowo omówione później.

przetwarzanie wstępne

możliwość łączenia plików i ładowania ich z zestawu wstępnie zdefiniowanych lokalizacji w naszej aplikacji jest wielką zaletą potoku zasobów. To dopiero początek. Ponieważ ładujemy zasoby przez szyny, możemy wstępnie przetworzyć pliki przy użyciu popularnych języków, takich jak SCSS, aby pisać lepsze CSS i Coffeescript dla czystszego JS. Jeśli tworzysz atut o nazwie theme.css.scss, mówisz potoku zasobów, aby uruchomić plik przez preprocesor SCSS przed serwowaniem motywu.css do przeglądarki. Preprocesor SCSS kompiluje plik do CSS. Jedyne, co musieliśmy zrobić, to dostarczyć poprawne rozszerzenie pliku, .scss, do pliku, a potok aktywów wie, aby uruchomić go przez preprocesor SCSS.

Odcisk Palca

ostatnią korzyścią, o której porozmawiamy, jest odcisk palca, ale najpierw porozmawiajmy o problemie, który pomaga nam rozwiązać. Kiedy serwujemy pliki do przeglądarki, są one prawdopodobnie buforowane, aby uniknąć ich ponownego pobierania w przyszłości. Co to jest buforowanie można zapytać?

buforowanie czegoś oznacza przechowywanie kopii czasochłonnej operacji lokalnie, dzięki czemu nie musisz ponownie ponawiać kosztownej operacji, jeśli wejścia i wyjścia będą dokładnie takie same. Bufory są zwykle kluczowymi magazynami wartości, gdzie wartość jest odpowiedzią na kosztowną operację, a klucz jest czymś, co jest unikalne dla tego elementu. Jeśli zażądasz strony z serwera, a następnie ponownie zażądasz tej samej strony z serwera, najszybszym sposobem spełnienia tego żądania jest zachowanie kopii tego, co ostatnio otrzymałeś lokalnie. Przeglądarki buforują wiele odpowiedzi, które dostają na złożone żądania, używając nagłówków wysyłanych z odpowiedzią. Nagłówki informują przeglądarkę, jak długo strona pozostaje „świeża”, zanim „wygaśnie”.’Po wygaśnięciu strony przeglądarka wyśle nowe żądanie odświeżenia pamięci podręcznej strony. Mówimy, że najszybszym żądaniem jest żądanie, które nie zostało złożone. Często mówi się również, że unieważnienie pamięci podręcznej jest jednym z dwóch trudnych problemów w informatyce, więc zastanów się uważnie, kiedy zaczniesz buforować rzeczy! Buforowanie oszczędza przepustowość dla nas i zapewnia zwiększenie prędkości dla użytkownika. Jest to świetne, dopóki nie zmienisz pliku i chcesz, aby wszyscy użytkownicy otrzymali nowy zamiast starej wersji, którą zapisali w pamięci podręcznej przeglądarki. Ale jak powiadomić przeglądarkę, że zmodyfikowaliśmy plik? Jeśli nowa wersja ma taką samą nazwę jak stara wersja, przeglądarka będzie nadal używać starego pliku z pamięci podręcznej. Potrzebujemy sposobu na zmianę nazwy pliku, gdy zawartość się zmieni, aby przeglądarki nie obsługiwały starego pliku.

z podkład Rails Guides

„odcisk palca jest techniką, która sprawia, że nazwa pliku zależy od zawartości pliku. Po zmianie zawartości pliku zmieniana jest również nazwa pliku. W przypadku zawartości, która jest statyczna lub rzadko zmieniana, zapewnia to łatwy sposób na stwierdzenie, czy dwie wersje pliku są identyczne, nawet na różnych serwerach lub w datach wdrożenia.

gdy nazwa pliku jest unikalna i opiera się na jego zawartości, nagłówki HTTP mogą być ustawione tak, aby zachęcić pamięć podręczną wszędzie (czy to w CDN, u dostawców usług internetowych, w sprzęcie sieciowym lub w przeglądarkach internetowych) do zachowania własnej kopii zawartości. Po zaktualizowaniu zawartości zmieni się odcisk palca. Spowoduje to, że klienci zdalni zażądają nowej kopii zawartości. Jest to znane jako Cache busting.

techniką, której używa się do fingerprintingu, jest dołączenie skrótu zawartości do końca nazwy pliku. Na przykład, weź plik CSS o nazwie global.css. Sprockets doda hash 908e25f4bf641868d8683022a5b62f54 na końcu nazwy pliku tak:

global-908e25f4bf641868d8683022a5b62f54.css

jeśli używasz starszej wersji Rails (Rails 2.x), dawniej strategia polegała na dołączaniu łańcucha zapytania opartego na dacie do każdego Zasobu połączonego z wbudowanym pomocnikiem. To wyglądało tak:

global.css?1309495796

strategia ciągu zapytań ma kilka wad:

  • nie wszystkie pamięci podręczne będą niezawodnie buforować zawartość, gdzie nazwa pliku różni się tylko parametrami zapytania.
    • Steve Souders zaleca ” unikanie querystring dla zasobów buforowalnych.”5-20% twoich żądań nie będzie buforowane. Ciągi zapytań w szczególności nie działają w ogóle z niektórymi CDN dla unieważnienia pamięci podręcznej.
  • nazwa pliku może zmieniać się między węzłami w środowiskach wieloserwerowych.
    • domyślny ciąg zapytania w Rails 2.x jest oparty na czasie modyfikacji plików. Gdy zasoby są wdrażane w klastrze, nie ma gwarancji, że znaczniki czasu będą takie same, co spowoduje użycie różnych wartości w zależności od tego, który serwer obsługuje żądanie.
  • za dużo unieważnienia pamięci podręcznej.
    • gdy zasoby statyczne są wdrażane z każdym nowym wydaniem kodu, mtime (czas ostatniej modyfikacji) wszystkich tych plików zmienia się, zmuszając wszystkich zdalnych klientów do ponownego ich pobrania, nawet jeśli zawartość tych zasobów nie uległa zmianie.

pobieranie odcisków palców rozwiązuje wszystkie te problemy, zapewniając spójność nazw plików w oparciu o ich zawartość.

pobieranie odcisków palców jest domyślnie włączone dla produkcji i wyłączone dla wszystkich innych środowisk. Możesz go włączyć lub wyłączyć w swojej konfiguracji za pomocą opcji config.assets.digest.”

wniosek

Potok zasobów jest zdecydowanie bardziej złożony niż tylko serwowanie zasobów z folderu publicznego i może być trudne do debugowania. Nauka korzystania z niego opłaci się na dłuższą metę, oszczędzając nam czas i bóle głowy. Pomyśl o wszystkich problemach, które nam rozwiązuje.

  1. ścieżki zasobów
  2. manifesty i Konkatenacje
  3. wstępne przetwarzanie
  4. Odcisk Palca

na koniec koniecznie sprawdź, w którym DHH wprowadza potok zasobów.