Sass похож на Pringles: как только ты щелкаешь, ты не можешь остановиться. После использования Sass для пары проектов, сбор ванильного CSS-проекта кажется странным. «Где мои переменные?» «Почему я не могу вкладывать вещи?» «Я просто хочу этот миксин…» Во всей нашей Sass-isfaction на самом деле довольно легко забыть, что есть разработчики, которые этого не делают или не может использовать препроцессор. И мы не должны забывать их или унижать их!
Существует множество ситуаций, когда вы можете передать сайт тому, кто не использует препроцессор. Некоторые разработчики заново запускают CSS и закрепляют это основное знание. Некоторые любят идеалы и простоту CSS и считают, что препроцессор добавляет ненужный раздув в их рабочий процесс. Другие могут работать с ограниченным набором инструментов и не имеют возможности запускать препроцессор там, где это необходимо. Я не говорю, что это все идеальные или идеальные ситуации, но у каждой есть мера обоснованности.
Если вы собираетесь разрабатывать в Sass, вам может понадобиться план игры, чтобы передать его разработчику без Sass. Давайте посмотрим, как обычно происходит этот процесс, и постараемся определить, как лучше всего завершить эту передачу.
Просто передайте им код и уходите.
Это, вероятно, значение по умолчанию: мы просто передаем код тому, кто его поддержит, и надеемся на лучшее. К сожалению, это также может быть наименее полезным методом.
Что происходит, когда мы даем клиенту или менеджеру сайта папку, полную паролей Sass и без инструкций? У меня нет никаких эмпирических доказательств в поддержку этой статистики, но я бы поспорил, что в девяти случаях из десяти каталог /sass/ Это проблема? Ну, если ты сжал свой вывод, да. Удачи даже опытному CSS-автору, который вносит изменения в сжатую таблицу стилей!
Если вы собираетесь предоставлять код без каких-либо инструкций препроцессора, вы должны быть готовы обработать все изменения, внесенные клиентом, если они когда-нибудь попросят вас сделать больше работы на сайте в будущем. Будьте готовы переместить все свои правки обратно в Sass и возобновить рабочий процесс или просто отредактировать CSS. Если есть хоть малейший шанс, что кто-то захочет снова использовать препроцессор на сайте, я рекомендую дать клиенту быстрое объяснение вашей настройки и предупреждение о том, что любые изменения, которые они вносят в скомпилированный CSS, могут быть перезаписаны, если будущий разработчик не заботится о возвращении в Sass.
Поставляйте только скомпилированный CSS.
Если вы знаете, что никто никогда не будет использовать ваши файлы Sass снова, я бы не стал включать их в результаты. В некоторых случаях я бы также рекомендовал предоставить унифицированную таблицу стилей для упрощения обслуживания. Я знаю, что это удар по производительности: если это касается вас, расскажите клиенту о плюсах и минусах производительности в сравнении с ремонтопригодностью и позвольте им взять на себя ответственность за решение. Если у вас есть инструмент производительности кэширования / минимизации / конкатенации, настроенный для поставляемого сайта (плагин WP, веб-сервис и т. Д.), Это спорный вопрос. Просто дайте им неинициализированный CSS, пусть они счастливо отредактируют его, и пусть инструмент производительности справится с минификацией.
Дайте им отдельную таблицу стилей «edits.css» для внесения изменений.
Мне не очень нравится эта идея. Производительность сильно падает, потому что вы добавляете еще один запрос к критическому пути, блокирующему рендеринг. Кроме того, этот метод случайно поощряет чрезмерную специфичность. Не все понимают, что позже CSS переопределяет предыдущий CSS, если селекторы имеют одинаковую специфику (я полагаю, для тех людей, это просто SS, а не CSS?) Кто-то вроде этого будет склонен заполнять свой файл edits.css!important
Однако, если вы передаёте квалифицированному специалисту по сопровождению CSS, и он доволен небольшим падением производительности (или использует минимизирующий / конкатенационный плагин для его отмены), это отличный способ сохранить все изменения в одном месте. и сохранить оригинальный Sass нетронутым для будущего разработчика.
Научите их, как использовать препроцессор.
Я слышу, как ты смеешься отсюда. Остановись на минуту и позволь мне объяснить! Я знаю, что это не будет работать для каждого клиента. Есть некоторые, для кого этот метод был бы катастрофой. Вы знаете, кого я имею в виду: есть люди «Я знаю немного CSS», а также люди, которые так мало разбираются, делают сотни вещей для своего стартапа, бизнеса или стороннего проекта, что у них нет пропускной способности для учиться Sass.
Но если у вас есть клиент, который может справиться с изучением нового шага, я бы предложил обучить его использовать настроенные вами параметры Sass. Это потребует вложений вашего времени и их времени. (Если бы я проводил тренировку «intro to Sass» с таким клиентом, я бы сделал ставку как минимум на полдня, возможно, на целый день.)
Помните, что вы профессионал, и вам нужно заплатить за это время. Если вы можете продать его своему клиенту в качестве дополнения к концу, больше возможностей для вас. С другой стороны, если вы думаете, что клиент действительно хорошо справится с этим обучением, но не будет платить за него дополнительно, добавьте стоимость вашего учебного дня в стоимость пакета сайта и добавьте это «бесплатно» в конце.
Вывод
Передача файлов Sass владельцам и сопровождающим сторонним сайтам, конечно же, не самая простая вещь. Однако при некотором планировании оно может быть успешным. Пожалуйста, оставьте комментарии с другими способами управления этой раздачей или рассказами о том, как один из этих методов сработал для вас!