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

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

темы

• Актив Трубопровод?
• организация
• Конкатенация и сжатие?
• Языки высокого уровня

Актив Трубопровод?

Конвейер активов не совсем новость для людей в бизнесе, но для начинающих может быть немного сложно быстро разобраться. Разработчики точно не тратят кучу времени на интерфейсные вещи, особенно когда они начинают. Они заняты множеством движущихся частей, которые не имеют ничего общего с HTML, CSS или часто разбитыми битами JS.

Конвейер активов может помочь, управляя объединением, минимизацией и предварительной обработкой ресурсов, например активов, написанных на языках высокого уровня, таких как CoffeeScript или Sass.

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

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

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

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

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

организация

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

• app/assets

Папка app/assets предназначена для ресурсов, специально предназначенных для этого приложения, — изображений, файлов JS и CSS, созданных специально для конкретного проекта.

• lib/assets

С другой стороны, папка lib/assets является домом для вашего собственного кода, который вы можете повторно использовать из проекта в проект — вещи, которые вы, возможно, сами извлекли и хотите перенести из одного проекта в другой, в частности, ресурсы, которые вы может делиться между приложениями.

• vendor/assets

vendor/assets — это еще один шаг наружу. Это дом для активов, которые вы повторно использовали из других внешних источников — плагинов и платформ от третьих лиц.

Это три места, в которых Sprockets будет искать активы. В указанных выше каталогах вы должны поместить свои ресурсы в папки /images , /stylesheets и /javascripts . Но это более обычная вещь; любые ресурсы в папках */assets будут просмотрены. Вы также можете добавлять подкаталоги по мере необходимости. Rails все равно не будет жаловаться и прекомпилировать свои файлы.

Существует простой способ взглянуть на путь поиска конвейера активов. Когда вы запускаете консоль Rails с консолью rails console , вы можете проверить ее с помощью следующей команды:

Терминал

То, что вы получите, — это массив со всеми каталогами ресурсов, которые доступны и найдены Sprockets — так называемый путь поиска.

Приятная вещь обо всем этом легко пропустить. Это аспект наличия соглашений. Это означает, что разработчики, а также дизайнеры, на самом деле, могут иметь определенные ожидания относительно того, где искать файлы и где их размещать. Это может сэкономить время (голос Трампа). Когда кто-то новый присоединяется к проекту, у него есть хорошая идея, как сразу перейти к проекту.

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

Упомянутые пути активов, однако, не в камне. Вы также можете добавить собственные пути. Откройте config/application.rb и добавьте пользовательские пути, которые вы хотите, чтобы Rails распознал. Давайте посмотрим, как бы мы добавили custom_folder .

config.application.rb

Теперь, когда вы снова проверите путь поиска, вы обнаружите, что ваша пользовательская папка является частью пути поиска для конвейера ресурсов. Кстати, теперь это будет последний объект, помещенный в массив:

Терминал

Выход

Конкатенация и сжатие?

Зачем нам это нужно? Короче говоря, вы хотите, чтобы ваши приложения загружались быстрее. Период! Все, что помогает с этим, приветствуется. Конечно, вы можете уйти, не оптимизируя для этого, но у него слишком много преимуществ, которые просто нельзя игнорировать. Сжатие размеров файлов и объединение нескольких файлов активов в один «главный» файл, который загружается клиентом, таким как браузер, также не такая большая работа. В любом случае, это в основном обрабатывается конвейером.

Сокращение количества запросов на рендеринг страниц очень эффективно ускоряет процесс. Вместо того, чтобы иметь 10, 20, 50 или любое другое количество запросов до того, как браузер завершит получение ваших ресурсов, вы потенциально можете иметь только один для каждого актива CSS и JS. Сегодня это приятно, но в какой-то момент это изменило правила игры. Этими улучшениями в веб-разработке не следует пренебрегать, потому что мы имеем дело с миллисекундами как единым целым.

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

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

Однако сжатие JS немного сложнее. Веб-браузеры не нуждаются в таком форматировании. Это позволяет нам оптимизировать эти активы. Главная проблема этого раздела заключается в том, что уменьшенное количество запросов и минимальные размеры файлов ускоряют работу и должны быть в вашем распоряжении. Rails предоставляет вам эту функциональность без дополнительных настроек.

Языки высокого уровня

Возможно, вы уже слышали о них, но, как новичок, вы не знаете, почему вы должны изучать еще один язык, особенно если вы все еще заняты изучением написания классического HTML и CSS. Эти языки были созданы для устранения недостатков, которые разработчики хотели устранить. В основном они решают проблемы, с которыми разработчики не хотели сталкиваться ежедневно. Классическая разработка, основанная на лени, я думаю.

«Языки высокого уровня» звучат более причудливо, чем могло бы быть, хотя они и радуются. Мы говорим о Sass, CoffeeScript, Haml, Slim, Jade и тому подобных вещах. Эти языки позволяют нам писать в (в основном) удобном для пользователя синтаксисе, с которым работать удобнее и эффективнее. Все они должны быть предварительно скомпилированы в процессе сборки.

Я упоминаю об этом, потому что это может произойти за кулисами без вашего ведома. Это означает, что он берет эти ресурсы и преобразует их в CSS, HTML и JS до того, как они будут развернуты и могут быть отображены браузером.

пререкаться

Sass расшифровывается как «Синтаксически удивительные таблицы стилей» и является гораздо более мощным, чем чистый CSS. Это позволяет нам писать более умные таблицы стилей, в которых есть несколько инструментов программирования. О чем мы здесь говорим? Вы можете объявлять переменные, вложить правила, писать функции, создавать миксины, легко импортировать партиалы и многое другое, что программисты хотели бы иметь доступным при игре со стилями.

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

Для ваших текущих задач есть две синтаксические версии Sass, о которых вам нужно знать. Версия Sassy CSS, также известная как SCSS, является наиболее распространенной. Он остается ближе к простому CSS, но предлагает все модные расширения, разработчики и дизайнеры полюбили играть с таблицами стилей. Он использует .scss файла .scss и выглядит так:

SCSS

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

SCSS

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

CSS

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

Как оно это делает? Без скобок Sass использует отступы, по существу, пробелы, для разделения своих свойств. Это довольно рад и выглядит действительно круто. Чтобы увидеть различия, я покажу вам обе версии рядом.

.sass

.scss

Довольно красиво и компактно, а? Но обе версии должны быть обработаны, прежде чем они превратятся в действительный CSS, понятный браузерам. Asset Pipeline позаботится об этом за вас. Если вы поразите браузеры чем-то вроде Sass, они не поймут, что происходит.

Я лично предпочитаю синтаксис с отступом. Этот чувствительный к пробелам синтаксис Sass менее популярен, чем синтаксис SCSS, что может не сделать его идеальным выбором для проектов, отличных от ваших личных. Вероятно, хорошей идеей будет выбрать самый популярный среди вашей команды вариант, особенно с привлечением дизайнеров. Принудительное использование пробелов в людях, которые годами укрощают все фигурные скобки и точки с запятой, кажется плохой идеей.

Обе версии имеют одинаковые приемы программирования. Они отлично делают процесс написания стилей намного более приятным и эффективным. Нам повезло, что Rails и Asset Pipeline позволяют так легко работать с любым из них — практически из коробки.

Slim & Haml

Аналогичные аргументы могут быть сделаны о преимуществах использования чего-то вроде Slim и Haml. Они очень удобны для создания более компактной разметки. Он будет скомпилирован в корректный HTML, но файлы, с которыми вы имеете дело, значительно уменьшены.

Вы можете избавить себя от необходимости писать закрывающие теги и использовать классные сокращения для названий тегов и тому подобное. Эти короткие всплески разметки легче просматривать и читать. Лично я никогда не был большим поклонником Haml, но Slim не только модный и удобный, но и очень умный. Для людей, которым нравится синтаксис Sass с отступом, я определенно рекомендую поиграть с ним. Давайте кратко рассмотрим:

Стройное

Haml

Оба приводят к следующему расширенному ERB HTML в Rails:

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

Как видите, оба препроцессора значительно сокращают объем записи. Да, вам нужно выучить другой язык, и сначала он выглядит немного странно. В то же время я чувствую, что устранение такого большого количества беспорядка полностью стоит того. Кроме того, как только вы научитесь писать HTML со вкусом ERB, вы сможете довольно быстро выбрать любой из этих препроцессоров. Нет ракетостроения — то же самое относится и к Sass, кстати.

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

CoffeeScript

CoffeeScript — это такой же язык программирования, как и любой другой, но у него есть тот Ruby-вкус для написания вашего JavaScript. Посредством предварительной обработки он компилируется в простой старый JavaScript, с которым могут работать браузеры. Короткий аргумент для работы с CoffeeScript состоял в том, что он помог преодолеть некоторые недостатки, которые JS носил с собой. Документация гласит, что она направлена ​​на то, чтобы показать «хорошие части JavaScript» простым способом. Справедливо! Давайте кратко рассмотрим короткий пример и посмотрим, с чем мы имеем дело:

JavaScript

В CoffeeScript этот парень будет выглядеть так:

CoffeeScript

Читает просто чуть лучше без всех кудрей и точек с запятой, нет? CoffeeScript пытается позаботиться о некоторых неприятных моментах в JavaScript, позволяет печатать меньше, делает код более читабельным, предлагает более удобный синтаксис и более приятен в написании классов. Определение классов было большим плюсом какое-то время, особенно для людей из Ruby, которые не очень любили иметь дело с чистым JavaScript. CoffeeScript использует схожий с Ruby подход и дает вам хороший кусочек синтаксического сахара. Классы выглядят так, например:

Учебный класс

Этот язык некоторое время был довольно популярен на земле Руби. Я не уверен, какова скорость принятия в наши дни, но CoffeeScript — это разновидность JS по умолчанию в Rails. В ES6 JavaScript теперь также поддерживает классы — одна из причин, по которой, возможно, не использовать CoffeeScript и вместо этого играть с простым JS. Я думаю, что CoffeeScript по-прежнему выглядит лучше, но многие из менее косметических причин его использования были устранены в ES6 в наши дни. Я думаю, что это все еще хорошая причина, чтобы попробовать, но это не то, что вы пришли сюда. Я просто хотел дать вам еще одну закуску и немного рассказать о том, почему конвейер активов позволяет вам работать в CoffeeScript «из коробки».

Последние мысли

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

Что мне больше всего нравится в этом, так это то, как мало хлопот это заставляет работать. Не поймите меня неправильно, инструменты вроде Gulp и Grunt также впечатляют. Вариантов для настройки множество. Я просто не могу избавиться от удобного ощущения, которое дает мне Rails, когда мне не нужно разбираться ни с какими настройками перед началом работы. Соглашения могут быть мощными, особенно если они приводят к чему-то беспроблемному и беспроблемному.